[Sip-implementors] A question about SDP direction attribute
As per RFC 3264, a missing direction attribute in offer SDP default is sendrecv. What is the default considered in case of Answer SDP? I assume that it should be again sendrecv and the default does not change whether it is offer or answer. If the hold answer comes without direction attribute but with connection line IP 0.0.0.0, should I consider this a valid hold answer? I am asking this question because in my inter-operation testing, one of the UE sends answer without direction attribute when I send offer with a=sendonly. ~Vikram ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] RE-INVITE Problem [packet capture inside]
Dale has covered this. For the original poster, Stefan: there is a lot of written information on this subject that you don't seem to be familiar with. The most obvious are RFCs 3261 and 3264. For a more complete treatment, see http://www.ietf.org/internet-drafts/draft-ietf-sipping-sip-offeranswer-02.txt Once you understand those I think your questions will be answered. Paul [EMAIL PROTECTED] wrote: >From: Stefan Sayer <[EMAIL PROTECTED]> > >The offerer may change the stream, but the answerer? > > Uh, yes. I answered a different question than was asked. > > In regard to how the answer may be different from the offer, the rules > are in section 6.1 of RFC 3264. In many cases, the answerer may add > media formats. E.g., > >For streams marked as sendrecv in the answer, the "m=" line MUST >contain at least one codec the answerer is willing to both send and >receive, from amongst those listed in the offer. 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). > > In any case, if one is trying to debug SDP, one should have read RFC > 3264 carefully. > >From: Stefan Sayer <[EMAIL PROTECTED]> > >And then, if you change any part of the SDP, you must update >(increase) the session version, which in both SDPs of the two 200s >is 1294106766. > > Interestingly, though the offers are identical, the answers are > different (and so should have different versions). > > Dale > ___ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] RE-INVITE Problem [packet capture inside]
From: Stefan Sayer <[EMAIL PROTECTED]> The offerer may change the stream, but the answerer? Uh, yes. I answered a different question than was asked. In regard to how the answer may be different from the offer, the rules are in section 6.1 of RFC 3264. In many cases, the answerer may add media formats. E.g., For streams marked as sendrecv in the answer, the "m=" line MUST contain at least one codec the answerer is willing to both send and receive, from amongst those listed in the offer. 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). In any case, if one is trying to debug SDP, one should have read RFC 3264 carefully. From: Stefan Sayer <[EMAIL PROTECTED]> And then, if you change any part of the SDP, you must update (increase) the session version, which in both SDPs of the two 200s is 1294106766. Interestingly, though the offers are identical, the answers are different (and so should have different versions). Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Special Information Tones
Hari, Yes, an example of where a SIT tone is used on the PSTN would be when the caller has dialed a bad or non-existing number. The SIT tone is generally played on the PSTN before a failure announcement. ITU recommendation E.182 defines tones that should be heard by the caller in various situations the PSTN. I've also pasted an excerpt of RFC 2833 for you about SIT: 3.12 Line Events ... ITU Recommendation E.182 [13] defines when certain tones should be used. It defines the following standard tones that are heard by the caller: ... Special information tone: The callee cannot be reached, but the reason is neither "busy" nor "congestion". This tone should be used before all call failure announcements, for the benefit of automatic equipment. ... When bridging between SIP and the PSTN you may want to use SIP response codes for certain errors to trigger recordings that start with SIT tones to be played to PSTN callers. Bayan Towfiq On Aug 8, 2007, at 12:31 AM, Hari Vuppaladhadiam wrote: > Hi > I wanted to understand when is SIT (Special Information Tone) > played? > Is this the error tone for BAd/Non-Existing number? > Can anyone point me to relevant RFC? > > Regards > Hari > > ___ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] few queries regarding SDP implementation formultiple bit rates for g.722 codec
Hi All, >>m=audio 9292 RTP/AVP 9 >>a=rtpmap:9 G722/48000 >>a=rtpmap:9 G722/56000 >>a=rtpmap:9 G722/64000 This is definitely incorrect. The only clock rate supported by G.722 is 16KHz, which should be specified as 8KHz for compatibility reasons (see RFC 3551 4.5.2). This means the offer should be: m=audio 9292 RTP/AVP 9 a=rtpmap:9 G722/8000 Everything else is not standard and is not supported (except specifying the number of channels, such as a=rtpmap:9 G722/8000/1). Also, there is almost no reason to use any other G.722 bit rate except 64KB. All of those bit rates actually occupy 64KB of bandwidth. Lower bite rates simply leave space for a side channel inside the audio stream, which, IMHO, is not extremely useful in an IP environments. Furthermore, you can decode all of these bit rates as 64KB with minimal affect on the audio quality. ___ Roman Shpount ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
[Sip-implementors] Special Information Tones
Hi I wanted to understand when is SIT (Special Information Tone) played? Is this the error tone for BAd/Non-Existing number? Can anyone point me to relevant RFC? Regards Hari ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] few queries regarding SDP implementation formultiple bit rates for g.722 codec
>>m=audio 9292 RTP/AVP 9 >>a=rtpmap:9 G722/48000 >>a=rtpmap:9 G722/56000 >>a=rtpmap:9 G722/64000 I'm not sure this would always work as desired. I think the effect will be that a receiver of this SDP will just end up selecting the last one in the list. Also, I think the rates are incorrect. The number after the '/' is the clock rate (or sample rate), not the bit rate. For example: a=rtpmap:0 PCMU/8000 is 8000 samples per second but 64kbits/second The 2nd version could work but you'd have to open multiple ports. The problem is that SDP wasn't really designed for capability negotiation. These problems are trying to be resolved here: http://tools.ietf.org/html/draft-ietf-mmusic-sdp-capability-negotiation-06 Regards, Attila -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Somesh S Shanbhag Sent: 06 August 2007 16:17 To: lalit kumar; Sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] few queries regarding SDP implementation formultiple bit rates for g.722 codec (Query 1) I think you can specify multiple a= lines in SDP m=audio 9292 RTP/AVP 9 a=rtpmap:9 G722/48000 a=rtpmap:9 G722/56000 a=rtpmap:9 G722/64000 (Query 2) m=audio 9292 RTP/AVP 9 0 a=rtpmap:9 G722/64000 a=rtpmap:0 PCMU/8000 m=audio 9296 RTP/AVP 9 18 a=rtpmap:9 G722/56000 a=rtpmap:18 G729/8000 m=audio 9298 RTP/AVP 9 a=rtpmap:9 G722/48000 (Query 3) Honestly dont know which one is better in network. Somesh lalit kumar <[EMAIL PROTECTED]> wrote: Help needed regarding G.722 codec negotiation. I have few queries regarding SDP implementation for multiple bit rates for g.722 codec. As we know that g.722 supports 48,56 and 64 kbps. Query-1: à I want to negotiate g.722 codec with multiple bitrates 64 56,and 48. Then what would be SDP attributes value in Sip invite. Query-2à if I have following codec order for negotiation, then what would be the SDP for Sip Invite? G.722 at 64 kbps PCMU G.722 at 56 kbps G.729 G.722 at 48 Kbps Query-3 à On network what flavor of G.722 codec is better at bit rates (64,56 or 48 kbps)? Please help me out, Thanks in advance. Thanks, Lalit -- Thanks & Regards Lalit Kumar ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors - SIMPLICITY IS THE BEAUTY. BE NATURAL LIVE NATURAL. - - Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] RE-INVITE Problem [packet capture inside]
Hello,
[EMAIL PROTECTED] wrote:
>From: Manjunath Warad <[EMAIL PROTECTED]>
>
>I have strong doubt on the SDP that is exchanged in 200 of
>Re-INVITE. Answerer has added other media formats that he supports and I
>don't think offerer would support those and hence offerer could be
> releasing
>the call by sending ACK and BYE.
>
> Why do you have doubt? Read RFC 3264 ("An Offer/Answer Model with the
> Session Description Protocol (SDP)"), section 8 ("Modifying the
> Session"), subsection 8.3 ("Modifying a Media Stream"), subsection
> 8.3.2 ("Changing the Set of Media Formats"):
>
>The list of media formats used in the session MAY be changed. To do
>this, the offerer creates a new media description, with the list of
>media formats in the "m=" line different from the corresponding media
>stream in the previous SDP. This list MAY include new formats, and
>MAY remove formats present from the previous SDP. However, in the
>case of RTP, the mapping from a particular dynamic payload type
>number to a particular codec within that media stream MUST NOT change
>for the duration of a session.
The offerer may change the stream, but the answerer? And then, if you
change any part of the SDP, you must update (increase) the session
version, which in both SDPs of the two 200s is 1294106766.
>
> Dale
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Regards
Stefan Sayer
--
iptego - VoIP security
www.iptego.de
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
