Another SIP dialog / session problem

[Mikael Magnusson]

Werner Dittmann wrote:
> Ok, I got the GSM stuff in - test will be done soon I hope.
> 
> What makes me wonder with Gizom is that fact that Gizmo answers our
> offer with a selection of medias that minisip does not support, at least
> was not contained in out offer
> 
> Minisip's offer was:
> 
>             Media Description, name and address (m): audio 31570 RTP/AVP 0 97 114 101
>             Media Attribute (a): rtpmap:0 PCMU/8000/1
>             Media Attribute (a): rtpmap:97 iLBC/8000
>             Media Attribute (a): fmtp:97 mode=20
>             Media Attribute (a): rtpmap:114 speex/8000/1
>             Media Attribute (a): rtpmap:101 telephone-event/8000
>             Media Attribute (a): fmtp:101 0-15
> 
> and Gizmo answered:
> 
>             Media Description, name and address (m): audio 46076 RTP/AVP 13 3 103 97 117 101
>             Media Attribute (a): rtpmap:13 CN/8000
>             Media Attribute (a): rtpmap:3 GSM/8000
>             Media Attribute (a): rtpmap:103 ISAC/16000
>             Media Attribute (a): rtpmap:97 iLBC/8000
>             Media Attribute (a): rtpmap:117 red/8000
>             Media Attribute (a): rtpmap:101 telephone-event/8000
>             Media Attribute (a): rtcp:5005
>             Media Attribute (a): nortpproxy:yes
> 
> (Forget about the 13 (Comfort Noise, IMHO that was inserted by ZFONE). In any case
> with the exception of 101 there is no real match (except a half match for 97). However,
> AFAIK the UAS shall put in its answer only those media types that were in common for
> both, the UAC and the UAS. Otherwise no communication is possible because the sender
> may choose a media type  that the receiver does not support.
> 
> As I interpret the specs this could be a correct understanding. Thus could it also be
> a problem with Gizmo?
> 
> What do you think about it?
> 

I think it's a valid answer according to RFC 3264, except that it should 
contain a "mode" parameter for the iLBC codec.

    RFC 3264 section 6.1 Unicast Streams:

    The stream MAY indicate additional media formats, not listed in the
    corresponding stream in the offer, that the answerer is willing to
    send or receive (of course, it will not be able to send them at this
    time, since it was not listed in the offer).

> Regards,
> Werner
> 
> BTW, what the heck is this 101 telephone-event/8000? I couldn't find it in the codecs.
> Werner

It's a payload type used for DTMF and other telephone events specified 
in RFC 2833.

Mikael