It's a challenge to offer all flavors of g729 and I have seen the UAs usually send annexb=yes when all flavors are configured. If the termination UA send annexb=no in the answer, there is a big chance that the origination UA would tear the call by sending a CANCEL even when it did support that codec. One way would be to use dynamic payloads and specify all codecs with different payload types. So 18 can be used for g729 annexb=yes, 103 can be g729annexb=no, 104 could be g729annexb=no with silence suppresion =yes ( for g729AB) and so on.
M. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, February 22, 2007 10:26 AM To: [email protected] Subject: Sip-implementors Digest, Vol 47, Issue 32 Send Sip-implementors mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors or, via email, send a message with subject or body 'help' to [EMAIL PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED] When replying, please edit your Subject line so it is more specific than "Re: Contents of Sip-implementors digest..." Today's Topics: 1. Re: SDP in 2xx response after reliable 18x (Paul Kyzivat) 2. SDP for G729 codec ([EMAIL PROTECTED]) 3. Re: SDP for G729 codec (Attila Sipos) 4. registration of multiple public user identities (Sigrid Thijs) 5. Re: FW: SDP and ptime in RFC4566 is faulty ([EMAIL PROTECTED]) 6. Re: SDP in 2xx response after reliable 18x (Victor Paulsamy) 7. SDP for G729 codec ([EMAIL PROTECTED]) 8. Re: FW: SDP and ptime in RFC4566 is faulty ([EMAIL PROTECTED]) ---------------------------------------------------------------------- Message: 1 Date: Wed, 21 Feb 2007 16:59:21 -0500 From: Paul Kyzivat <[EMAIL PROTECTED]> Subject: Re: [Sip-implementors] SDP in 2xx response after reliable 18x To: Paul Kyzivat <[EMAIL PROTECTED]> Cc: Jerry Yin <[EMAIL PROTECTED]>, [email protected] Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Paul Kyzivat wrote: > If the IVR is acting as a B2BUA, as above, then the call flow you show > is incorrect. There are two things the IVR can do that are correct: > > - after receiving the 200 from the GW, the IVR can send a 200 to the UAC > with sdp2. After receiving the ACK, it can then send a reinvite with > sdp3. (But beware - the call flows necessary to get the UAC and the GW > agreeing on the SDP are subtle. See RFC 3725.) > > - make F2 be a reliable provisional, which then ends an offer/answer > cycle. Then, at F5, send an UPDATE with sdp3. (Again you will need > to do some stuff from 3725.) The 200 for the > invite will then preferably contain no sdp. Some further thoughts: Its also possible for the B2BUA to use the fake forking approach. And it will be simpler than either of the two above. Better yet, the IVR need not be a B2BUA. It can act as a UAS for the early media IVR response, and then act as a proxy for sending the call to the GW. Not only does this simplify the call flow, it also means that the IVR need not be involved in the call once it goes to the GW. Paul ------------------------------ Message: 2 Date: Thu, 22 Feb 2007 11:45:47 +0530 From: [EMAIL PROTECTED] Subject: [Sip-implementors] SDP for G729 codec To: [email protected] Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hi, I have some confusion on the usage of G729 and its siblings. Also how to represent G729 and it siblings in SDP. Here are my doubts. If a end point UA ( let say X) supports G729, G729A, G729B and G729AB and other end point UA ( let say Y) supports G729 and G729A. Now when X wants to send the offer (SDP in INVITE) to other UA (say Y) to know that it supports all the fours variants of G729 then how can X say so. What i understand is it is not possible to offer all G729 variant at same time. It is either G729A( compatible with G729) or G729B(compatible to G729AB) which can be offered at any time. Correct me if i am wrong here. If X comes up annexb=yes in the offer, then what will be the answer from Y. Will it respond with annexb=no since it does not support G729B or will it reject the offer with 488 response. Regards -venkat ------------------------------ Message: 3 Date: Thu, 22 Feb 2007 11:06:29 -0000 From: "Attila Sipos" <[EMAIL PROTECTED]> Subject: Re: [Sip-implementors] SDP for G729 codec To: <[EMAIL PROTECTED]>, <[email protected]> Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset="iso-8859-1" I believe that "annexb=yes" in an offer is a capability. It means annexb is supported. So if "annexb=yes" in the offer, then Y should respond with: annexb=no (then both sides won't do annexb) (Now if X requires (not just supports) annexB then it can kill the call with a CANCEL or a BYE and an appropriate Reason cause (RFC3326)) Regards, Attila -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED] Sent: 22 February 2007 06:16 To: [email protected] Subject: [Sip-implementors] SDP for G729 codec Hi, I have some confusion on the usage of G729 and its siblings. Also how to represent G729 and it siblings in SDP. Here are my doubts. If a end point UA ( let say X) supports G729, G729A, G729B and G729AB and other end point UA ( let say Y) supports G729 and G729A. Now when X wants to send the offer (SDP in INVITE) to other UA (say Y) to know that it supports all the fours variants of G729 then how can X say so. What i understand is it is not possible to offer all G729 variant at same time. It is either G729A( compatible with G729) or G729B(compatible to G729AB) which can be offered at any time. Correct me if i am wrong here. If X comes up annexb=yes in the offer, then what will be the answer from Y. Will it respond with annexb=no since it does not support G729B or will it reject the offer with 488 response. Regards -venkat _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors ------------------------------ Message: 4 Date: Thu, 22 Feb 2007 15:15:00 +0100 From: Sigrid Thijs <[EMAIL PROTECTED]> Subject: [Sip-implementors] registration of multiple public user identities To: [email protected] Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hi, in IMS there's a lot spoken about having multiple public user identities for a single private user identity. I was wondering what should happen when one single UE wants to register two public user identities for the same private user identity. I cannot find information about this in the IMS documentation, so please direct me to it, if there exists some. I think for each public identity, a REGISTER request should be sent. The To and From header of the REGISTER request should contain the public identity to be registered. But what about the Call-ID? According to RFC 3261, section 10.2 Constructing the REGISTER Request, all registrations from a UAC should use the same Call-ID header field value for registrations sent to a particular registrar. Does this apply to REGISTER requests for the same public identity or to *all* REGISTER requests sent from the UE? kind regards, Sigrid ------------------------------ Message: 5 Date: Wed, 21 Feb 2007 21:47:39 +0000 From: [EMAIL PROTECTED] Subject: Re: [Sip-implementors] FW: SDP and ptime in RFC4566 is faulty To: [email protected] Message-ID: <[EMAIL PROTECTED] cast.net> Content-Type: text/plain Hi, I just ran some tests with various brands of phones and none send ptime in their SDP, which makes this harder to understand. Here is one from a polycom. Are you saying that even though 3 media formats are listed, they are represented as one media stream? Is there an example of one that includes multiple media streams you can point me to. I guess I am now thoroughly confused. When my SIP gateway sends g729a10 and g729a20 to a snom, the call fails because only ptime 10 is listed and the phone is only configured to receive g729a20. But, as I mentioned, my SIP GW wants to talk 10 or 20. However, if I make a call to the SIP GW, it connects at 729a20. Does this make any sense at all? Session Description Protocol Session Description Protocol Version (v): 0 Owner/Creator, Session Id (o): - 1172011391 1172011391 IN IP4 10.153.90.9 Owner Username: - Session ID: 1172011391 Session Version: 1172011391 Owner Network Type: IN Owner Address Type: IP4 Owner Address: 10.153.90.9 Session Name (s): Polycom IP Phone Connection Information (c): IN IP4 10.153.90.9 Time Description, active time (t): 0 0 Session Start Time: 0 Session Stop Time: 0 Session Attribute (a): sendrecv Media Description, name and address (m): audio 2224 RTP/AVP 0 8 18 Media Type: audio Media Port: 2224 Media Proto: RTP/AVP Media Format: ITU-T G.711 PCMU Media Format: ITU-T G.711 PCMA Media Format: ITU-T G.729 Media Attribute (a): rtpmap:0 PCMU/8000 Media Attribute Fieldname: rtpmap Media Format: 0 MIME Type: PCMU Media Attribute (a): rtpmap:8 PCMA/8000 Media Attribute Fieldname: rtpmap Media Format: 8 MIME Type: PCMA Media Attribute (a): rtpmap:18 G729/8000 Media Attribute Fieldname: rtpmap Media Format: 18 MIME Type: G729 > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > [EMAIL PROTECTED] > Sent: Wednesday, February 21, 2007 2:09 PM > To: [email protected] > Subject: Re: [Sip-implementors] SDP and ptime in RFC4566 is faulty > > From: "Vick, Steven" > > There in lies the problem. The Aspect endpoint is sending two media > streams. > > There are two media streams being offered, but the Ptime is only > represented for the first one on the list. This happens regardless of > how many media streams (or whether they're the same codec type) are > in > the SDP. This is why I see the ptime in the rfc as needing some > enhancements. > > No, it's only offering one media stream, because there is only one "m" > line in the SDP: > > Session Description Protocol > Session Description Protocol Version (v): 0 > Owner/Creator, Session Id (o): - 1171987362 1171987362 IN > IP4 10.153.96.5 > Session Name (s): Aspect Communications SDP Session > Connection Information (c): IN IP4 10.153.96.5 > Time Description, active time (t): 0 0 > Media Description, name and address (m): audio 10034 RTP/AVP > 18 18 101 > Media Title (i): telephone-event 8000 > Connection Information (c): IN IP4 10.153.96.5 > Media Attribute (a): sendrecv > Media Attribute (a): ptime:10 > Media Attribute (a): rtpmap:18 G729/8000 > Media Attribute (a): fmtp:18 annexb=no > Media Attribute (a): rtpmap:18 G729/8000 > Media Attribute (a): fmtp:18 annexb=no > Media Attribute (a): rtpmap:101 telephone-event/8000 > > All the "a" lines offer altnerative encodings to be used within the one > media stream. As you note, SDP has the limitation that only one ptime > attribute can be given for a single media stream. If you want to be > able to use more than one ptime, you have to offer one media stream for > each ptime. > > Dale > > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors ------------------------------ Message: 6 Date: Wed, 21 Feb 2007 10:23:01 -0800 From: "Victor Paulsamy" <[EMAIL PROTECTED]> Subject: Re: [Sip-implementors] SDP in 2xx response after reliable 18x To: "Paul Kyzivat" <[EMAIL PROTECTED]>, "Attila Sipos" <[EMAIL PROTECTED]> Cc: "Sanjay Sinha \(sanjsinh\)" <[EMAIL PROTECTED]>, "Sweeney, Andrew \(Andrew\)" <[EMAIL PROTECTED]>, [email protected], Ira Kadin <[EMAIL PROTECTED]>, "Christer Holmberg \(JO/LMF\)" <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset="us-ascii" Paul, -> -> INVITE w/offer1 -> <- 18x (reliable) w/answer1 -> -> PRACK w/offer2 -> <- 200 PRACK w/answer2 -> <- 200 INVITE w/answer1 -> -> ACK -> -> The above is a legal flow. The caller *should not* end up using answer1. -> How do you say that this is a legal flow when "200 INVITE w/answer1" broke the "consistent" view of O/A across UAC & UAS -- the primary goal of O/A exchange? Thanks in advance. --victor ------------------------------ Message: 7 Date: Thu, 22 Feb 2007 11:06:38 +0530 From: [EMAIL PROTECTED] Subject: [Sip-implementors] SDP for G729 codec To: [email protected] Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hi, I have some confusion on the usage of G729 and its siblings. Also how to represent G729 and it siblings in SDP. Here are my doubts. If a end point UA ( let say X) supports G729, G729A, G729B and G729AB and other end point UA ( let say Y) supports G729 and G729A. Now when X wants to send the offer (SDP in INVITE) to other UA (say Y) to know that it supports all the fours variants of G729 then how can X say so. What i understand is it is not possible to offer all G729 variant at same time. It is either G729A( compatible with G729) or G729B(compatible to G729AB) which can be offered at any time. Correct me if i am wrong here. If X comes up annexb=yes in the offer, then what will be the answer from Y. Will it respond with annexb=no since it does not support G729B or will it reject the offer with 488 response. Regards -venkat ------------------------------ Message: 8 Date: Thu, 22 Feb 2007 10:25:36 -0500 From: [EMAIL PROTECTED] Subject: Re: [Sip-implementors] FW: SDP and ptime in RFC4566 is faulty To: [email protected] Message-ID: <[EMAIL PROTECTED]> From: [EMAIL PROTECTED] I just ran some tests with various brands of phones and none send ptime in their SDP, which makes this harder to understand. Here is one from a polycom. Are you saying that even though 3 media formats are listed, they are represented as one media stream? Is there an example of one that includes multiple media streams you can point me to. RFC 4317, "Session Description Protocol (SDP) Offer/Answer Examples", section 2.1: v=0 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com s= c=IN IP4 host.atlanta.example.com t=0 0 m=audio 49170 RTP/AVP 0 8 97 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 iLBC/8000 m=video 51372 RTP/AVP 31 32 a=rtpmap:31 H261/90000 a=rtpmap:32 MPV/90000 This contains specifications for two media streams, because there are two "m" lines. I guess I am now thoroughly confused. When my SIP gateway sends g729a10 and g729a20 to a snom, the call fails because only ptime 10 is listed and the phone is only configured to receive g729a20. That makes sense. But, as I mentioned, my SIP GW wants to talk 10 or 20. However, if I make a call to the SIP GW, it connects at 729a20. Does this make any sense at all? You say "if I make a call to the SIP GW", but you do not specify what UA is making the call, nor what SDP it is sending. Session Description Protocol Session Description Protocol Version (v): 0 Owner/Creator, Session Id (o): - 1172011391 1172011391 IN IP4 10.153.90.9 Owner Username: - Could you please quote SDP as SDP rather than the extremely verbose Ethereal expansion of SDP? Dale ------------------------------ _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors End of Sip-implementors Digest, Vol 47, Issue 32 ************************************************ _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
