Re: [Sip-implementors] Global and local - SIP URI
prashanth.me wrote: > Hi Paul, > Example SIP URI given by Iñaki Baz, does not contain the ;user=phone > parameter. > Should we assume that the userinfo part of the below SIP URI is a > telephone-subscriber number or not? > - > > sip:12345678;phone-context=mydomain@provider.com Who is "we"? The server responsible for provider.com will *know* what this represents. Others that are privy to the policies of provider.com may also know. But in general, somebody not aware of those specific policies will not *know* if this represents a telephone-subscriber or not. It can *assume* this if it wants, but then must understand that this is a guess that may be wrong. In any case, what would somebody else do with this if it knew this represented a telephone-subscriber? Is it to display the URI in a more user-friendly way? Or to route requests in ways that bypass provider.com? As far as sip standards are concerned, requests to this address need to reach a server for provider.com. You can of course do whatever you are comfortable doing. But there are no guarantees you are doing the right thing. Thanks, Paul > ----- > > Thanks, > Prashanth M E > > Paul Kyzivat wrote: >> The form of the user part is really the responsibility of the owner of >> the domain. user=phone is really only meaningful if the domain owner >> allows/supports that. In absence of user=phone, the domain may *choose* >> to treat the user part according to tel uri syntax, or not. >> >> *if* user=phone is present, and *if* the domain supports use of >> user=phone, then a user part that doesn't start with "+" must be a local >> number in accord with telephone-subscriber, as Iñaki says below. >> >> Paul >> >> Iñaki Baz Castillo wrote: >> >>> El Viernes 05 Marzo 2010, hanifa.mohammed escribió: >>> >>>> Thanks for the response. Pl clarify my assumption. >>>> >>>> 1. So, when there is no "user=phone" parameter in the SIP uri, there is no >>>> context of Local or Global. >>>> Or is there any other way to figure out whether a SIP uri is global or >>>> local? >>>> 2. Simply the presence of '+' in the userinfo part of the SIP uri is not >>>> suffice enough to declare it as >>>> a global SIP uri. >>>> >>> If ;user=phone is present you can assume that the SIP URI userinfo is a >>> telephone-subscriber number, following same rules (if it begins with "+" >>> then >>> it's absolute). In order to be local it would be like: >>> >>> sip:12345678;phone-context=mydomain@provider.com >>> >>> >>> >> ___ >> 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 > ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] [sipcore] RFC 3263 - why require use port in Request-URI?
Nancy Greene wrote: > Ok, thanks, but what about this paragraph? >If the TARGET was not a numeric IP address, but a port is present in >the URI, the client performs an A or record lookup of the domain >name. The result will be a list of IP addresses, each of which can >be contacted at the specific port from the URI and transport protocol >determined previously. The client SHOULD try the first record. If >an attempt should fail, based on the definition of failure in Section >4.3, the next SHOULD be tried, and if that should fail, the next >SHOULD be tried, and so on. When there is an intermediate hop before reaching the R-URI (your assumption), then the URI for that intermediate hop is the *target*, not the R-URI. This would typically by in the Route header, though you can choose an intermediate destination by configuration as well if you wish. In any case, it is only when the *next* hop is what is present in the R-URI that the port number in the R-URI is of concern. You will find a long section on target selection in 3261. You might want to ask one of the other Ericsson people that participate in ietf for help on this. (E.g. Christer Holmberg, Gonzalo Camarillo) Thanks, Paul > Nancy > > -----Original Message- > From: Paul Kyzivat [mailto:pkyzi...@cisco.com] > Sent: March-15-10 10:42 AM > To: Nancy Greene > Cc: SIP-implementors mailing list > Subject: Re: [sipcore] RFC 3263 - why require use port in Request-URI? > > switching to sip-implementors list > > Nancy Greene wrote: >> Thanks for the answer, but I'd like to know why the RFC is written the way >> it is. >> >> What if there is an intermediate SIP proxy between the target in the >> Request-URI and the proxy trying to reach it? That intermediate SIP proxy >> does not allow traffic on the port mentioned in the Request-URI, so the >> request fails to reach the target. This does not seem right. Shouldn't the >> RFC at the very least require a retry at the port that the intermediate >> proxy expects traffic on? > > I think you must be missing something fundamental. > > I think the following describes what you are asking about: > > C - P -- S > > where the message from C is something like: > > INVITE sip:f...@s.com:12345 > Route: sip:p.com > ... > > In the above case C would be sending the request to P using the result of SRV > lookup on p.com. The port number in the R-URI is irrelevant to how the > request is sent to P. > > Once the request reaches P, it will then use the R-URI to decide where to > forward the request. So then the port number 12345 will be relevant. > > Thanks, > Paul > >> Nancy >> >> -Original Message- >> From: Paul Kyzivat [mailto:pkyzi...@cisco.com] >> Sent: March-15-10 9:08 AM >> To: Nancy Greene >> Cc: sipc...@ietf.org >> Subject: Re: [sipcore] RFC 3263 - why require use port in Request-URI? >> >> Nancy, >> >> Questions such as this should be brought to >> . >> >> To answer your question... >> >> The port from the URI is to be used *if* it is present in the URI. >> (Would you prefer to *ignore* it?) >> >> If the the port is *not* present in the URI, then the port is obtained from >> DNS via the SRV query. That is explained further on in the same section of >> the document. >> >> Thanks, >> Paul >> >> >> Nancy Greene wrote: >>> I have a question on section 4.2 of RFC 3263: >>> >>> Why is it that the port of the Request-URI is required to be used for an >>> intermediate proxy? Is the issue that it is not known whether the next hop >>> proxy is intermediate or is the actual destination in the Request-URI? >>> >>> If so shouldn't there at least be a procedure described to use the port >>> from DNS instead of the one in the Request-URI if sending to the one in the >>> Request-URI fails? >>> >>> Section 4.2 from RFC 3263 (locating SIP servers): >>> >>> If the TARGET was not a numeric IP address, but a port is present >>> in the URI, the client performs an A or record lookup of the >>> domain name. The result will be a list of IP addresses, each of which >>> can be contacted at the specific port from the URI and transport >>> protocol determined previously. >>> >>> Nancy >>> >>> >>> ___ >>> sipcore mailing list >>> sipc...@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> > ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] [sipcore] RFC 3263 - why require use port in Request-URI?
switching to sip-implementors list Nancy Greene wrote: > Thanks for the answer, but I'd like to know why the RFC is written the way it > is. > > What if there is an intermediate SIP proxy between the target in the > Request-URI and the proxy trying to reach it? That intermediate SIP proxy > does not allow traffic on the port mentioned in the Request-URI, so the > request fails to reach the target. This does not seem right. Shouldn't the > RFC at the very least require a retry at the port that the intermediate proxy > expects traffic on? I think you must be missing something fundamental. I think the following describes what you are asking about: C - P -- S where the message from C is something like: INVITE sip:f...@s.com:12345 Route: sip:p.com ... In the above case C would be sending the request to P using the result of SRV lookup on p.com. The port number in the R-URI is irrelevant to how the request is sent to P. Once the request reaches P, it will then use the R-URI to decide where to forward the request. So then the port number 12345 will be relevant. Thanks, Paul > Nancy > > -Original Message- > From: Paul Kyzivat [mailto:pkyzi...@cisco.com] > Sent: March-15-10 9:08 AM > To: Nancy Greene > Cc: sipc...@ietf.org > Subject: Re: [sipcore] RFC 3263 - why require use port in Request-URI? > > Nancy, > > Questions such as this should be brought to > . > > To answer your question... > > The port from the URI is to be used *if* it is present in the URI. > (Would you prefer to *ignore* it?) > > If the the port is *not* present in the URI, then the port is obtained from > DNS via the SRV query. That is explained further on in the same section of > the document. > > Thanks, > Paul > > > Nancy Greene wrote: >> I have a question on section 4.2 of RFC 3263: >> >> Why is it that the port of the Request-URI is required to be used for an >> intermediate proxy? Is the issue that it is not known whether the next hop >> proxy is intermediate or is the actual destination in the Request-URI? >> >> If so shouldn't there at least be a procedure described to use the port from >> DNS instead of the one in the Request-URI if sending to the one in the >> Request-URI fails? >> >> Section 4.2 from RFC 3263 (locating SIP servers): >> >> If the TARGET was not a numeric IP address, but a port is present >> in the URI, the client performs an A or record lookup of the >> domain name. The result will be a list of IP addresses, each of which >> can be contacted at the specific port from the URI and transport >> protocol determined previously. >> >> Nancy >> >> >> ___ >> sipcore mailing list >> sipc...@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Terminating the dialog when there is no reply for an in-dialog OPTIONS
This is addressed by RFC 5057. The transaction times out and fails, but neither the dialog nor the invite dialog usage are affected. Thanks, Paul Iñaki Baz Castillo wrote: > Hi, an easy scenario: > > - A calls C through a B2BUA and the call is established with direct > audio between A and C. > > - A sends an in-dialog OPTIONS but B2BUA replies nothing (ignores the > request) due to a bad implementation or SIP stack. > > - After ~32 seconds A decides that the dialog is dead and terminates > the call (stops sending RTP). > > > In this case A doesn't require to send a BYE as an in-dialog request > has not been answered by B2BUA so the dialog is clearly broken. > > Well A could generate a BYE with a very high CSeq (at least greater > than the failed OPTIONS) and send it to B2BUA but it's, for sure, not > required at all. > > My question is: could somebody please point me to the exact point in > RFC 3261 in which this is explained? I need it to document a failure > in a SIP device. I have no doubt about that the above is 100% correct > (A is not required to send such BYE), but I have to document it and > cannot find the exact specification in RFC 3261. > > Any reference in RFC 3261 please? Thanks a lot. > > ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Mid call supported/require option tags modification
Specifically regarding session timer: every UPDATE or reINVITE renegotiates the use/non-use of the timer and the timer value. So you may start with it off, and later turn it on, or start with it on and later turn it off. If you're not careful, you may start with it on and inadvertently turn it off. Having said that, the value of changing this mid-call is questionable. The primary value of session-timer is for true proxies that record-route and want some ongoing indication of the status of the session. It doesn't do them much good unless it is there for the duration, since they can't initiate a change on their own. The UAC and UAS, and B2BUA intermediaries, don't need session timeer, because they can initiate an UPDATE or reINVITE or other message any time they are curious about the state of the session, without bothering with session timer. For the general case, there is nothing to prevent you from making changes in Supported/Required options mid-dialog. The duration of validity of these things is not well specified in any general way, though it may be for some specific ones. In general you can only assume they are valid for the duration of a single transaction. Of course if you use Required mid-call you do potentially run the risk of that *request* being rejected. But even then, that will not break your dialog. Thanks, Paul Balu Meenakshi-a24053 wrote: > Hi All, > How to implement the mid call supported/required option tag > modification? > For e.g. at the start of the call Session timer is not supported, > mid-call I want to add this, is this allowed. > > Not only for session timer in general is it Ok to add/remove the > supported/required option tags in > mid call requests. > > Please comment on this. > > Thanks & Regards > -Meena > > ___ > 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] Offer-answer question
the way 3264 is worded, any of the codecs in the offer may be used to send toward the offerer, and any of the codecs in the answer may be used to send toward the answerer. However in practice I think you will find that many implementations only support sending and receiving using codecs in the intersection of the offer and the answer. Thanks, Paul Neel Neelakantan wrote: > See below. > >> -Original Message- >> From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip- >> implementors-boun...@lists.cs.columbia.edu] On Behalf Of Michael >> Hirschbichler >> Sent: Friday, March 12, 2010 8:52 AM >> Cc: sip-implementors@lists.cs.columbia.edu >> Subject: Re: [Sip-implementors] Offer-answer question >> >> Thx, >> >> this is also my opinion. >> To point it down: there is no way to use G726 in *any* direction >> without >> Re-INVITEs - is this correct? >> > [Neel] > Since the offer contains G726, the endpoint A should be prepared to receive > G726. No Re-INVITE is necessary. > > Thanks, > Neel. > >> BR >> Michael >> >> Am 12.03.2010 15:48, schrieb Arunachala: >>> Not entirely true. A& B can talk using both G729 and PCMA. Either >> one >>> can switch between these two codecs without the use of a reINVITE. >>> >>> -Arun >>> >>> On Fri, Mar 12, 2010 at 7:34 PM, Aneesh Naik >> wrote: Hi Michael, This will not be allowed. A (UAC) has sent all the codecs it >> supports, and B (UAS) has respoded with the codecs it is willing to talk to A >> for this call. Only one codec will be negotiated for media transfer between A >> and B. In your example below, the negotiated codec is G.729, so both the >> parties must send media on G.729 codec. If the codec needs to change it between, then there can be a Re- >> NVITE to change the codec, and both parties once aggreed will start talking >> on that new codec negotiated. Thanks, Aneesh On Fri, Mar 12, 2010 at 7:14 PM, Michael Hirschbichler< s...@hirschbichler.biz> wrote: > Hi all, > > In my specific test-case, client A sends an INVITE offering some >> codecs > and client B answers with a 200OK containing a subset of these >> codecs. > Is it allowed for client B to transmit media using a codec >> presented in > the offer of client A but not acknowledged in the answer of client >> B? > e.g.: > > client A sends: > INVITE > m= G726, G729, G723, PCMA, PCMU > > client B responses: > 200OK > m= G729, PCMA > > the resulting media-exchange: > > AG729>B > A> is this allowed? Must A accept the G726-media? > > BR and thx in advance > Michael > ___ > 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 >>> ___ >>> 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 > > ___ > 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] Global URIs - different phone-contexts
Attila Sipos wrote: > So this leads me to another question: > > What is the practical difference between: > sip:+12345...@domain.org;user=phone > and > sip:+12345...@anotherdomain.org;user=phone and tel:+12345678 > ? > > Is it that in the first case, the request gets sent to "domain.org" > but in the seconds case, it is sent to "anotherdomain.org"? > > Are there any other differences? That is the difference. And the third case can be sent anywhere (and via any protocol) that gets to the place that a pstn call to that number would get. > Am I right that both requests should get sent to +12345678 on the PSTN? Not necessarily. Once the request gets to the domain, its the server at that domain that decides what happens next. It is under no formal obligation to send it to the pstn, or to a place that also receives pstn calls to that number, though that is a common expectation. This is especially notable if the number is not a pstn number that the domain is responsible for. In that case it might accept and forward it, or it might reject it. This property is a distinct disadvantage of the sip uri. For instance, - you send an invite to sip:+12345...@domain.org;user=phone. - When it gets there, the owner of that phone has set up forwarding to his mobile phone. This causes a redirect to sip:+13456...@domain.org;user=phone. - you (from outside domain.org) send another invite to sip:+13456...@domain.org;user=phone. - when this reaches domain.org, it decides its not forwarding calls out of its domain (to the cell provider) on behalf of callers outside its own domain, so it returns a 404 response. (Or pick the error of your choice.) - now you have to pick up the pieces and decide what to do. If the 3xx had been to tel:+13456789 then it would have been clear that it was your problem to find a path there. I guess the "normal" fixup for something like this is for an SBC to patch the URL in the 3xx. But I don't know what it should patch it to. Thanks, Paul An advantage of the sip form is that ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Global and local - SIP URI
The form of the user part is really the responsibility of the owner of the domain. user=phone is really only meaningful if the domain owner allows/supports that. In absence of user=phone, the domain may *choose* to treat the user part according to tel uri syntax, or not. *if* user=phone is present, and *if* the domain supports use of user=phone, then a user part that doesn't start with "+" must be a local number in accord with telephone-subscriber, as Iñaki says below. Paul Iñaki Baz Castillo wrote: > El Viernes 05 Marzo 2010, hanifa.mohammed escribió: >> Thanks for the response. Pl clarify my assumption. >> >> 1. So, when there is no "user=phone" parameter in the SIP uri, there is no >> context of Local or Global. >> Or is there any other way to figure out whether a SIP uri is global or >> local? >> 2. Simply the presence of '+' in the userinfo part of the SIP uri is not >> suffice enough to declare it as >> a global SIP uri. > > If ;user=phone is present you can assume that the SIP URI userinfo is a > telephone-subscriber number, following same rules (if it begins with "+" then > it's absolute). In order to be local it would be like: > > sip:12345678;phone-context=mydomain@provider.com > > ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] RFC 2833 / RFC 4733 - question on duration "0"
Yes. You could also send to . Its an active enough place with people that are likely to have insight into what others are doing. Thanks, Paul Vinay Pande (vipande) wrote: > Emailing the authors of 4733 sounds like a good 1st step, since this can > become important as 4733 gains acceptance. > Will you be doing that? if yes, please include Naidu, Girish and myself > apart from anyone else you feel should be on it, > > Thanks, > Vinay > > > > > *From:* Maulik Shah (maushah) > *Sent:* Tuesday, February 23, 2010 9:28 AM > *To:* Vinay Pande (vipande); artg-sip-bliss(mailer list); Toleti Danayya > Naidu (naidud); Paul Kyzivat (pkyzivat) > *Subject:* RE: RFC 2833 / RFC 4733 - question on duration "0" > > Hi Vinay > > > > I think the 3^rd party vendor is going to claim RFC4733 compatibility > and apparently in that RFC there is this section on backwards compatibility: > > > > The memo has been significantly restructured, incorporating a large > >number of clarifications to the specification. *With the exception of* > > * those items noted below*, the changes to the memo are intended to be > >backwards-compatible clarifications. However, due to inconsistencies > >and unclear definitions in RFC 2833 [12] it is likely that some > >implementations interpreted that memo in ways that differ from this > >version. > > > > … > > > > *Section 2.3.5* introduces the possibility of "state" events and > >defines procedures for setting the duration field for reports of such > >events. > > > > Reading through the above seems to suggest that duration = 0 is not > meant to be backwards compatible possibly though its not explicitly > stated. I think this may become a larger issue for us as more vendors > adopt RFC4733 and follow the above. Wonder if this requires an email to > the authors to see what should be done unless there are other thoughts. > > > > Thanks > > Maulik > > > > SBTG Product Marketing > > Cisco Systems > > 408 525 7827 > > Small Business Support Community > <https://www.myciscocommunity.com/community/smallbizsupport?view=overview> > > > > *From:* Vinay Pande (vipande) > *Sent:* Tuesday, February 23, 2010 12:09 AM > *To:* Maulik Shah (maushah); artg-sip-bliss(mailer list); Toleti Danayya > Naidu (naidud); Paul Kyzivat (pkyzivat) > *Subject:* RE: RFC 2833 / RFC 4733 - question on duration "0" > > > > -Q1- I dont think 2833 spells it out explicitly that 0 is not allowed - > it is one of those "gray" areas of RFCs I guess...but we never had a > problem with other vendors so far -- Why doesnt the other vendor's box > read and plan the packet with duration of 400? > > -Q2- Looking at the sec 2.3.5, we seem to be in violation of 4733, since > 0 seems to be a special duration (forever) > > -Q3- If RFC 2833 doesnt in anyway say that 0 is an illegal duration, > then this is more of a problem that they havent maintained b/ward > compatibility between 4733 and 2833. > > Ideally, the 3rd party GW should be lenient in accepting this -- there > are many such instances where you are strict when sending, but lenient > when you receive something...especially when RFCs are not b/ward compatible > > > > Thanks, > Vinay > > > > > > > > *From:* Maulik Shah (maushah) > *Sent:* Monday, February 22, 2010 10:11 PM > *To:* artg-sip-bliss(mailer list); Toleti Danayya Naidu (naidud); Paul > Kyzivat (pkyzivat); Vinay Pande (vipande) > *Subject:* RFC 2833 / RFC 4733 - question on duration "0" > > All > > Hope this is the right mailer – trying to get my head around something > odd causing an interop issue with the Cisco SIP stack and a 3^rd party: > > > > Setup: > > phone – Cisco SIP GW – SIP – 3^rd party GW > > > > When dialing digits using RFC2833 on the phone, here is what the Cisco > GW sends when user pressed digit 1: > > > > *CISCO* > > DTMF EVENT # > > > > END > > > > DURATION > > > > VOLUME > > 1 > > > > FALSE > > > > * 0 * > > > > 10 > > 1 > > > > FALSE > > > > * 0 * > > > > 10 > > 1 > > > > FALSE > > > > *
Re: [Sip-implementors] Unattended Call Transfer
If you aren't interested in the NOTIFY, you can use the norefersub option to bypass the subscription altogether. Alternatively you could use the information about a failure to alert the transfering user in some way - display a message, blink, etc. From a practical perspective, I think a user that does an unattended call transfer would probably like to know if it doesn't succeed. Thanks, Paul Bajaj, Gagandeep wrote: > Hi > Bob sends NOTIFY "terminated" (15th message) to inform Alice that he has > successfully connected with Carol. > > Till Alice gets NOTIFY "terminated", it keeps the dialog details. > > > > My question is: > > 1) Why after doing an unattended transfer and sending BYE to Bob, > Alice would be interested in the last NOTIFY? > > 2) Do commercial UAs do anything with the body of this NOTIFY > "terminated"? > > 3) If say NOTIFY "terminated" body contains "Failure response to > Bob-Carol INVITE", what action Alice takes (generally seen) ?? > > > > > > Thanks > > > > Gagandeep Bajaj > > > > > > > > > ___ > 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] Multiple redirect responses in single transaction
oh, duh! Of course you are right. What was I thinking? Sorry, Paul Anders Kristensen wrote: > Paul, > > Unless I'm much mistaken proxies can only forward one non-2xx final > response upstream. Multiple early-dialogs don't change that. > > Thanks, > Anders > > On 2/22/2010 1:40 PM, Paul Kyzivat wrote: >> At end... >> >> Aaron Clauson wrote: >>>> -Original Message- >>>> From: Dale Worley [mailto:dwor...@avaya.com] >>>> Sent: Monday, 22 February 2010 4:42 PM >>>> On Thu, 2010-02-18 at 02:50 +, Aaron Clauson wrote: >>>> >>>> You should be able to do this in a standard way. >>>> >>>> First, let us assume that an address of the client (which is acting as >>>> UAS in this situation) is. >>>> >>>> The incoming request is "METHOD sip:UAS". Once the client obtains the >>>> first redirect URI,, it responds "SIP/2.0 302 Moved >>>> Temp/Contact: sip:DEST1/Contact:". >>>> >>>> This causes the requestor to fork to, but the requestor >>>> also >>>> forks to. The latter request goes back to the >>>> client, >>>> bit it is tagged so the client knows to proceed with the second phase >>>> of >>>> processing for the request. >>>> >>> The problem I have is that the client does not actually know all the >>> redirects at the point the first one is sent. The client has a human user >>> pressing buttons to initiate the redirects and there could be gaps of >>> 1,2,5,10 etc. seconds between subsequent forwards. >>> >>> In the meantime I went ahead and used a custom info response of "184 >>> Multiple Redirect" which does the job perfectly. >> Well, that is entirely proprietary. And if you are putting the "redirect >> URIs" into the 184 as Contact headers, then you are also messing up >> dialog state. >> >> I didn't fully understand what Dale was suggesting, but I can suggest >> someting along the same lines: >> >> The trick is that you want to send a 3xx, but you want the option to >> send another 3xx later. You can't do that in the same early dialog, but >> you can do it in multiple early dialogs. But to do that you must >> convince the caller that there is another dialog to wait on. >> >> So, >> >> When your server decides it wants to do this, it should send a 183 >> response a to-tag defining an early dialog. This should be a reliable >> 1xx if you are permitted to do that. >> >> Then when it has an address it wants to send back, it can send a 3xx, >> but with a *different* to-tag. (This indicates you forked the call and >> the 3xx is from a different leg.) >> >> If you later have another address to return, repeat the above with a >> different to-tag. >> >> When you are done playing these games, you can send the final address in >> a 3xx with the same to-tag as the 183. Or if you have no more addresses, >> just return 480 with that to-tag. >> >> That's all fully standards compliant, and should elicit the right >> behavior from any caller that is capable of doing something reasonable >> with multiple 3xx responses. >> >> Thanks, >> Paul >> ___ >> 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 > ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Multiple redirect responses in single transaction
At end... Aaron Clauson wrote: >> -Original Message- >> From: Dale Worley [mailto:dwor...@avaya.com] >> Sent: Monday, 22 February 2010 4:42 PM >> On Thu, 2010-02-18 at 02:50 +, Aaron Clauson wrote: >> >> You should be able to do this in a standard way. >> >> First, let us assume that an address of the client (which is acting as >> UAS in this situation) is . >> >> The incoming request is "METHOD sip:UAS". Once the client obtains the >> first redirect URI, , it responds "SIP/2.0 302 Moved >> Temp/Contact: sip:DEST1/Contact: ". >> >> This causes the requestor to fork to , but the requestor >> also >> forks to . The latter request goes back to the >> client, >> bit it is tagged so the client knows to proceed with the second phase >> of >> processing for the request. >> > > The problem I have is that the client does not actually know all the > redirects at the point the first one is sent. The client has a human user > pressing buttons to initiate the redirects and there could be gaps of > 1,2,5,10 etc. seconds between subsequent forwards. > > In the meantime I went ahead and used a custom info response of "184 > Multiple Redirect" which does the job perfectly. Well, that is entirely proprietary. And if you are putting the "redirect URIs" into the 184 as Contact headers, then you are also messing up dialog state. I didn't fully understand what Dale was suggesting, but I can suggest someting along the same lines: The trick is that you want to send a 3xx, but you want the option to send another 3xx later. You can't do that in the same early dialog, but you can do it in multiple early dialogs. But to do that you must convince the caller that there is another dialog to wait on. So, When your server decides it wants to do this, it should send a 183 response a to-tag defining an early dialog. This should be a reliable 1xx if you are permitted to do that. Then when it has an address it wants to send back, it can send a 3xx, but with a *different* to-tag. (This indicates you forked the call and the 3xx is from a different leg.) If you later have another address to return, repeat the above with a different to-tag. When you are done playing these games, you can send the final address in a 3xx with the same to-tag as the 183. Or if you have no more addresses, just return 480 with that to-tag. That's all fully standards compliant, and should elicit the right behavior from any caller that is capable of doing something reasonable with multiple 3xx responses. Thanks, Paul ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Query - are *header* parameters (other than tag) of From and To part of dialog state?
Roman Shpount wrote: > From/To header should be preserved completely with all of its parameters > to be compatible with RFC 2543. RFC 3261 Section 11.2 Callee Issues > Response says that "The response MUST copy the To, From, Call-ID, CSeq > and Via fields from the request." This implies that complete header, > including all the header parameters are copied. The RFC 3261 should > still match the request based on To and From tags. Older, RFC 2543 based > user agents, will only match request to dialog if complete To and From > headers are preserved. That is pertinent to the *response* to the request. The question is about subsequent requests within the dialog. Thanks, Paul ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Query - are *header* parameters (other than tag) of From and To part of dialog state?
Brett Tate wrote: >> Question is: Should the To in that (re)INVITE >> contain ';foo=bar' ??? >> >> AFAIK the contents of that To header are to be generated >> from dialog state information. The URI and the tag are >> part of that state, but other header parameters from the >> original INVITE are not, and hence would not be available >> for the addressing of subsequent messages. >> >> Does anyone have a different opinion? > > Partially. > > >> If so, can you justify it? > > If really supposed to only use dialog state information, all the RFCs showing > display-name within To and From of requests within dialog are incorrect: > rfc3665, rfc3666, rfc5359, and etcetera. > However AFAIK, rfc3261 is silent concerning if To and From's non dialog > related content should or should not continue to be sent within subsequent > requests within dialog. I don't take it to be a MUST to only use the dialog state. If you *want* to preserve some other stuff, or just change it arbitrarily, I see no reason why you can't. But I can't require you to do so. > Concerning your foo=bar question, I agree that it is valid to drop the > parameter. Sections 20.20 and 20.39 (and silence of 12.2.1.1) indicate that > it is valid. However as you noticed, such behavior can cause > interoperability problems. Thanks, Paul ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Query - are *header* parameters (other than tag) of From and To part of dialog state?
Iñaki Baz Castillo wrote: > El Miércoles, 17 de Febrero de 2010, Paul Kyzivat escribió: >> AFAIK the contents of that To header are to be generated from dialog >> state information. The URI and the tag are part of that state, but other >> header parameters from the original INVITE are not, and hence would not >> be available for the addressing of subsequent messages. >> >> Does anyone have a different opinion? >> If so, can you justify it? > > I also expect that keeping the From/To tags are enough while keeping other > From/To header parameters is not required for an in-dialog request. > > If Alice wants to keep more custon info within the dialog she/it could add > such parameters to Contact URI in the first parameter, right? They could be added as Contact URI params, or as From URI params. Thanks, Paul ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
[Sip-implementors] Query - are *header* parameters (other than tag) of From and To part of dialog state?
I got queried about this when an interop problem popped up. I know what I think the right answer is, but want to check what others think. Here is the case: Alice calls Bob: INVITE ... From: ;tag=;foo=bar this succeeds and a dialog is established. Then, within that dialog, Bob sends a request to Alice. E.g. INVITE ... To: ;tag= Question is: Should the To in that (re)INVITE contain ';foo=bar' ??? AFAIK the contents of that To header are to be generated from dialog state information. The URI and the tag are part of that state, but other header parameters from the original INVITE are not, and hence would not be available for the addressing of subsequent messages. Does anyone have a different opinion? If so, can you justify it? Thanks, Paul ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] CSeq of retried INVITE
Once the first INVITE has failed, and early dialog it might have had is gone. The retried INVITE is working toward establishing a new dialog. So the CSeq values are for that dialog. I think that means the CSeq numbering should be permitted to restart. OTOH, if there are any messages still in transit from the prior attempt, they could be a problem if the numbering resets. Thanks, Paul ViVeK tAlWaR wrote: > According to RFC 3261 > > > > "CSeq or Command Sequence contains an integer and a method name. The > >CSeq number is incremented for each new request within a dialog and > >is a traditional sequence number. > > " > > > > CSeq increment is not done for specific request it is done for all the > request in the dialog. > > > > Regards, > > Vivek > > _ > > From: sip-implementors-boun...@lists.cs.columbia.edu > [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of > Dushyant Dhalia > Sent: Friday, January 29, 2010 4:52 PM > To: OKUMURA Shinji > Cc: sip-implementors@lists.cs.columbia.edu > Subject: Re: [Sip-implementors] CSeq of retried INVITE > > > > It must be greater that or equal to 3. > > Dushyant P S Dhalia > > OKUMURA Shinji wrote: > > Hi, > > I have a question regarding CSeq of retried INVITE. > > Consider the following scenario. > > | INVITE(CSeq:1)| > |--->| > || > | 18x | > |<---| > || > | PRACK(CSeq:2) | > |--->| > || > | 200 OK(PRACK) | > |<---| > || > | 415 | > |<---| > || > | ACK | > |--->| > || > | INVITE(CSeq:2)| > |--->| > | with the same Call-ID | > || > > > according to the section 8.1.3.5 in RFC3261, 2nd INVITE > "SHOULD have the same value of the >Call-ID, To, and From of the previous request, but the CSeq should >contain a new sequence number that is one higher than the previous." > > therefore, I think the CSeq of 2nd INVITE SHOULD be "2". > > Is my understanding correct? > > Regards, > Shinji > ___ > 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] Is anonymous user allowed in sip-uri with user=phone?
To be anonymous with a tel URI, just lie and use somebody else's number. Or, you could do something like: tel:0;phone-context=anonymous.invalid But AFAIK there is no *standard* way of doing it. Thanks, Paul Iñaki Baz Castillo wrote: > El Miércoles, 13 de Enero de 2010, Paul Kyzivat escribió: >> This says that if the user field contains an e164 telephone-subscriber >> than user=phone SHOULD be present. It doesn't state the converse: that >> if the user part *doesn't* contain a telephone-subscriber then there >> should not be a user=phone. >> >> So I don't think this can be viewed as a syntactic error. It needs to be >> considered a semantic distinction and only considered by something >> responsible for the domain that has knowledge of the semantics of user >> names in that domain. > > BTW, how to indicate anonymous caller in a TEL URI? perhaps it's not possible > (due to grammar restrictions) so a SIP URI must be used for this purpose? > > ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Is anonymous user allowed in sip-uri with user=phone?
I'm going to get a bit nit-picky here. The text from 3261 says: The set of valid telephone-subscriber strings is a subset of valid user strings. The user URI parameter exists to distinguish telephone numbers from user names that happen to look like telephone numbers. If the user string contains a telephone number formatted as a telephone-subscriber, the user parameter value "phone" SHOULD be present. Even without this parameter, recipients of SIP and SIPS URIs MAY interpret the pre-@ part as a telephone number if local restrictions on the name space for user name allow it. This says that if the user field contains an e164 telephone-subscriber than user=phone SHOULD be present. It doesn't state the converse: that if the user part *doesn't* contain a telephone-subscriber then there should *not* be a user=phone. So I don't think this can be viewed as a syntactic error. It needs to be considered a semantic distinction and only considered by something responsible for the domain that has knowledge of the semantics of user names in that domain. Thanks, Paul Brett Tate wrote: >>> In case it matters, "anonymous" does violate the character >>> set for the digits portion of telephone-subscriber. Thus >>> although maybe not desirable, a strict parser may reject >>> the INVITE with a 400 response. >> It's just a semantic subject. No strict SIP parser should >> reject such SIP URI even if its username part doesn't conform >> to telephone-subscriber grammar when "user=phone" parameter >> is present. > > The sender indicated user=phone when user portion cannot really be decoded > (per BNF character restrictions) into a telephone-subscriber. Thus a vendor > may choose to reject the request. > > Concerning the topic, I've heard of a vendor's protocol monitor (or similar > device not directly involved within the call) being overly restrictive > concerning ability to decode telephone-subscriber when user=phone. If I > recall correctly, the user portion of sip-uri was "anonymous" or there was no > user portion. The abnormal situation was causing them problems; I have no > idea if they have relaxed their decoder. > > >> I've tested it with my SIP parser which is 100% strict >> according to RFC 3261 grammar and RFC 3966 (TEL). Such >> SIP URI is valid according to BNF. > > Does your parser allow invalid characters within the local-number-digits or > does it not allow "anonymous;phone-context=national" to successfully decode > into a telephone-subscriber? > > > ___ > 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] Is anonymous user allowed in sip-uri with user=phone?
Iñaki Baz Castillo wrote: > El Miércoles, 13 de Enero de 2010, ROHIT CHAUDHARY escribió: >> Hi experts, >> >> A sip-uri with user part as "anonymous" is allowed. But if the user >> parameter is phone, ie, the user part is to be treated as >> telephone-subscriber of tel-url (RFC 3966), then should it be allowed, >> something like this: >> >> > > As you said, "if the user parameter is phone the user part is to be treated > as > telephone-subscriber of tel-url (RFC 3966)". > > Of course, "anonymous" is not a valid TEL number so the above SIP URI (which > comes from a TEL URI due to the presence of "user=phone") makes no sense > (IMHO). It makes no sense. But the decision that it makes no sense is up to a server for the domain of the URI. So this should not be objected to until it reaches a server for the host1.com domain. It will then have the job of interpreting the user part of the URI, and will presumably reject it. But if it *wants* to accept it, I guess it may. Thanks, Paul > In order to get a better anonymous URI I would use just: > > From: Anonymous ;tag=1928301774 > > This is, with no "user" param. However RFC 3261 doens't specify very well how > to set an "anonymous" URI/sender. > >> Is this a valid sip-url or should it be answered with 400 Bad Request? > >>From the point of view of the SIP ABNF grammar it's correct. > > ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Need info on Call-ID
Rajanikanth wrote: > But in RFC5627(GRUU) it's mentioned that Call-ID can change in register > refresh requests,if UA wants to invalidate temp-gruu. > Can we change call-ID in the register refresh requests? Sure you can change the callid from one REGISTER request to another. In that case it is, as far as the registrar is concerned, not a refresh but rather an entirely new registration. Thanks, Paul > -- > Thanks, > Rajanikanth > > Uttam Sarkar wrote: >> RFC 3261 says: >> >> In section 10.3 >> >> >> Call-ID: All registrations from a UAC SHOULD use the same Call-ID >>header field value for registrations sent to a particular >>registrar. >> >>If the same client were to use different Call-ID values, a >>registrar could not detect whether a delayed REGISTER request >>might have arrived out of order. >> >> >> >> -Original Message- >> From: sip-implementors-boun...@lists.cs.columbia.edu >> [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of >> Rajanikanth >> Sent: Tuesday, December 22, 2009 11:28 PM >> To: sip-implementors@lists.cs.columbia.edu >> Subject: [Sip-implementors] Need info on Call-ID >> >> Hi All, >> >> When can a Call-ID changes in SIP Registration with regard to GRUU. >> >> -- >> Thanks, >> Rajanikanth >> ___ >> 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 > ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Query related to SUBSCRIBE - NOTIFY behavior w.r.t. proxy server
Pandurangan R S wrote: >> In such a case UAC and NOTIFIER would destroy then SUBSCRIBE >> dialog quietly. > > NOTIFIER will destroy the dialog as per RFC3265. > But how/why did the UAC destroy subscribe dialog? I think it has to > wait for the NOTIFY. > >> Now my questions are - >> 1. Does the proxy server have to start a timer for receipt of NOTIFY? >> 2. What should be the value of such a timer, if any? > > NOTIFY can come after quite a long time (authorization may take a long > time, if interacting with user, a primary reason that > subscription-state is *finally* conveyed in a NOTIFY message, a > separate transaction) This is wrong. INVITE can take a long time, which is why the invite transaction has its own state machine and the ACK. SUBSCRIBE is a normal sip transaction, and times out like one, after (IIRC) 32 seconds. Re the original question: Did the proxy Record-Route? If not then it won't see the NOTIFY anyway. The recent clarifications to SUB/NOT (in progress) make it clear that the dialog/dialog-usage for SUBSCRIBE is established by the NOTIFY, not by the SUBSCRIBE. So if the proxy is dialog stateful, then it can capture some *tentative* state based on the SUBSCRIBE, and then watch for NOTIFYs. (The SUBSCRIBE may be forked.) When/if it sees them it can establish actual dialog state. If the SUBSCRIBE transaction times out without there having been any NOTIFYs, then the proxy can forget the whole thing. Thanks, Paul >> 3. Won't this timer be, if there's any, similar to session-expires timer? > > Anyway, subscribe dialog lifetime is bound (even at proxy, if dialog > stateful) based on expires header 2xx response for subscribe. So I > don't think any other timer is required. > > On Mon, Dec 14, 2009 at 5:43 PM, Dushyant Dhalia > wrote: >> The scenario is as follows - >> >> 1. UAC sends SUBSCRIBE. >> 2. Proxy forwards SUBSCRIBE to the NOTIFIER. >> 3. NOTIFIER sends 200 (OK) which is received by the UAC. >> 4. NOTIFIER sends NOTIFY which is lost, retransmissions are also lost. >> >> As per RFCs 3265 and 5057 subscribe usage should be destroyed in such a >> scenario. See sec. 4.2 of RFC 5057 (NOTIFY or refresh-SUBSCRIBE request >> timeout). In such a case UAC and NOTIFIER would destroy then SUBSCRIBE >> dialog quietly. >> >> Now my questions are - >> 1. Does the proxy server have to start a timer for receipt of NOTIFY? >> 2. What should be the value of such a timer, if any? >> 3. Won't this timer be, if there's any, similar to session-expires timer? >> >> Regards, >> Dushyant P S Dhalia, >> Rancore Technologies, INDIA >> >> -- >> "When work is a pleasure, life is a joy! When work is duty, life is >> slavery." >> >> ___ >> 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 > ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] SIP proxy to drop off from a SIP chain
If your proxy refrains from adding itself to the Record-Route header, it will not remain in the chain. (You must take overt action to stay in.) But note this is for *proxies*, not B2BUAs. Paul Mihaly Zachar wrote: > Hi Gents, > > > How is it possible to drop off a SIP chain after the call setup ? > > I need to write a proxy which forwards the call from A to B, but after > the first transaction (INVITE, 18x, 200 OK, ACK) it should drop off the > SIP chain. > Any other messages should go between the 2 peers (A<->B). > > Is it allowed by the RFC3261 ? > What are the key steps, how can I do it ? > > Any comments are welcome. > > Best regards, > Misi > > ___ > 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] Glare condition with BYE and re-INVITE requests
IMO it would be inappropriate to send a 491 in this case, because it is not glare, and it is perfectly ok to terminate the dialog. Given that it has sent the BYE, I *think* it would be ok for S to send a 481 to the reinvite. (But I haven't scrutinized the state machines regarding this.) If not 481, it can find some response for the reINVITE. But I think A should respond 200 to the BYE. Thanks, Paul Vishal Agrawal wrote: > Hi, > > Assume that phone “A” issues a re-INVITE request to the SIP server “S” and > at the same time “S” issues a BYE request to “A”. > > Is it valid for “A” to send a 491 response to this BYE request from “S”? > > The SIP INVITE dialog is for a point to point media session. > > Here is the quote from the Section 15.1.2 in RFC 3261 – > > “A UAS core receiving a BYE request for an existing dialog MUST follow the > procedures of Section 12.2.2 to process the request. Once done, the UAS > SHOULD terminate the session (and therefore stop sending and listening for > media). The only case where it can elect not to are multicast sessions, > where participation is possible even if the other participant in the dialog > has terminated its involvement in the session. Whether or not it ends its > participation on the session, the UAS core MUST generate a 2xx response to > the BYE, and MUST pass that to the server transaction for transmission.” > >>From the above, my understanding is that “A” must send a 200 OK response for > this BYE request regardless of it terminating the SIP session or not, is > this understanding correct? > >>From reading the sections 14.2 and 21.4.27, it seems RFC 3261 mentions 491 > response for INVITE requests only in glare conditions. Is it valid and a > good idea to send a 491 response for the BYE request when a re-INVITE client > transaction is pending? > > Lastly – “UAS SHOULD terminate the session” – why is this requirement at > SHOULD level? If the far-end “S” wants to terminate the session and has sent > a BYE request, mustn’t “A” terminate the session and expect a 487 from “S” > for its re-INVITE? > > Thanks, > Vishal > ___ > 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] Handling retransmission for 200 OK- whenBYEreceived, before ACK for INVITE
Remember that there are two views of whether a dialog exists: one by the UAC and one by the UAS. The goal is for them to agree, but there are points in time when they don't agree. So when the UAS sends a response < 300 with to-tag, *it* thinks there is a dialog. This is true regardless of whether the response is provisional or final, reliable or not. When the UAC receives such a response, then *it* knows there is a dialog, and that the UAS agrees with that understanding. The ACK (or PRACK) allows the UAS to know that UAC and UAS agree there is a dialog. Thanks, Paul sunil.bha...@wipro.com wrote: > Thanks a lot. > > Regards, > Sunil > > -Original Message- > From: Ritul Sonania [mailto:ri...@in.niksun.com] > Sent: Wednesday, December 09, 2009 2:35 PM > To: Sunil Bhagat (WT01 - Telecom Equipment) > Cc: sip-implementors@lists.cs.columbia.edu; > zhiqiang.z...@alcatel-sbell.com.cn > Subject: RE: [Sip-implementors] Handling retransmission for 200 OK- > whenBYEreceived, before ACK for INVITE > > >> Does this mean that there is no dialog?? Since 200 OK was lost in the >> network? Or would the UAS maintain dialog information based on 200 OK >> which it had sent... even though it was lost? > > I suggest you read the RFC Section 13.3.1.4 > >The 2xx response is passed to the transport with an >interval that starts at T1 seconds and doubles for each >retransmission until it reaches T2 seconds (T1 and T2 are defined in >Section 17). Response retransmissions cease when an ACK request for >the response is received. This is independent of whatever transport >protocols are used to send the response. > >If the server retransmits the 2xx response for 64*T1 seconds without >receiving an ACK, the dialog is confirmed, but the session SHOULD be >terminated. > > Regards, > Ritul Sonania > >> Regards, >> Sunil >> >> -Original Message- >> From: Ritul Sonania [mailto:ri...@in.niksun.com] >> Sent: Wednesday, December 09, 2009 12:59 PM >> To: Sunil Bhagat (WT01 - Telecom Equipment) >> Cc: sip-implementors@lists.cs.columbia.edu; >> zhiqiang.z...@alcatel-sbell.com.cn >> Subject: RE: [Sip-implementors] Handling retransmission for 200 OK- >> whenBYEreceived, before ACK for INVITE >> >> >>> Hi, >>> >>> What if 200 OK is lost in the network?? Shouldn't it be ACK that >>> guarantees a successful dialog creation? >>> >> A UAC should send the ACK only when it has received the final > response. >> So, >> in case 200 OK is lost, no ACK would be transmitted. >> >> Regards, >> Ritul Sonania >> >>> Regards, >>> Sunil >>> >>> -Original Message- >>> From: Ritul Sonania [mailto:ri...@in.niksun.com] >>> Sent: Wednesday, December 09, 2009 12:27 PM >>> To: Sunil Bhagat (WT01 - Telecom Equipment) >>> Cc: sip-implementors@lists.cs.columbia.edu; >>> zhiqiang.z...@alcatel-sbell.com.cn >>> Subject: RE: [Sip-implementors] Handling retransmission for 200 OK- >>> whenBYEreceived, before ACK for INVITE >>> >>> Hi All, I have a question here. Does 200 Response guarantees that a dialog has been established? > Or >> is it the ACK which confirms establishment of a successful dialog? >>> >>> Hi Sunil, >>> >>> A final response (200 OK) is sufficient to create a dialog; ACK is > not >>> used >>> for creating dialog. A provisional response creates "early" dialog. >>> >>> Thanks, >>> Ritul Sonania >>> Thanks, Sunil -Original Message- From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf > Of ZHAO Zhiqiang Sent: Wednesday, December 09, 2009 9:32 AM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] Handling retransmission for 200 OK- > when BYEreceived, before ACK for INVITE Hello sudhagar, Dale , Rahul A. Jadhav The retransmission for 200OK to INVITE is processed by TU layer( >>> Please check 3261 Page 134), not transaction layer. after sent a 200OK > for INVITE, server transaction will transit to TERMINATE state > according >>> to INVITE SERVER TRANSACTION state diagram. so , I think TU layer received BYE, then it should be stop retransmission for 200 OK, How do you think? Best regards Andy /// You should always see 200 OK retransmissions in this case, until > the >>> UAS receives the ACK or the transaction times out. On receiving BYE, the transaction layer would treat it as a >> different transaction altogether and wont try to relate it in anyway to the >>> INVITE transaction. Thus transaction layer would handover the BYE to the > TU >>> and TU would respond back with a 200 OK since it already had the session created for which it received BYE. Also, transaction layer cannot relate the BYE transaction to
Re: [Sip-implementors] UPDATE recieve with SDP without completeing provisional response.
To be charitable, we should assume that the UAC is trying to do the right thing. So presumably it *sent* the PRACK (which was then lost or delayed), and then sent the UPDATE without awaiting the reply to the prack. The UAS can infer from the UPDATE with offer that the 183 was received, and that the PRACK could not have contained an offer. So I think it is justified in "being liberal" and responding to the UPDATE as if things were fine. The fact that the UAC didn't wait for the response to the prack, and yet is upset with receiving the response to the UPDATE before the response to the PRACK is then presumably its problem. An alternative approach that the UAS could take to this case is to simply ignore (lose) the UPDATE. That will cause it to be retransmitted. In the meantime the PRACK will hopefully show up. Thanks, Paul vijaya yadav wrote: > Hi Kinnu, > > Yes, UAC is at fault here but in this case what should do UAS if PRACK is > droped on network or not send from UAC and UAS receive the Update message > with SDP. > > Regards > VYADAV > > On Thu, Dec 3, 2009 at 12:52 PM, Kanta C wrote: > >> I think the UAC is at fault here. It should have responded with a PRACK for >> the 183 and then 200 OK for UPDATE. >> >> >> Regards, >> Kinnu >> >> >> -- >> *From:* vijaya yadav >> *To:* sip-implementors@lists.cs.columbia.edu >> *Sent:* Thu, December 3, 2009 12:30:00 PM >> *Subject:* [Sip-implementors] UPDATE recieve with SDP without completeing >> provisional response. >> >> Hi >> >> >> >> <- INVITE (SDP) >> >> -->183(SDP) (100rel) >> >> PRACK not received from the UAC >> >> <-UPDATE(SDP) >> >> -->200OK(SDP) [Is this correct message or UAS send any 4xx message] >> >> -->183 retransmitted >> >> ->500 Internal server error >> >> >> >> >> >> What is the behaviour of UAS if not recievd the PRACK of 183 and recieve a >> UPDATE message with new offer >> >> >> >> >> ~Vijaya >> ___ >> 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 > ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Any real case of a TEL/SIP URI with parameters as user?
Iñaki Baz Castillo wrote: > El Martes, 1 de Diciembre de 2009, Paul Kyzivat escribió: > >>> So, is there any SIP core in which such URI's exist for its users? >>> Of course "they COULD exist", however I want to know if they *really* >>> exist :) >> I'm curious why you ask. >> >> Are you considering an implementation that cannot support such use? > > I'm coding a XCAP server. The HTTP request URI contains a XUI field with the > user (SIP/TEL URI) whose document is desired. > > I must decide how to code that HTTP URI parser for the case in which a XUI is > a SIP/TEL URI with params: > > a) Allow it but just take the URI ignoring the URI params. > b) Allow it and treat the full URI (including parameters) as username. > c) Reject it as I don't allow URI parameters in XUI. > > I really assume that the only open door is the case of TEL URI with local > number (so ";phone-context" param is required as per RFC 3963), but I know no > cases of a user with such local TEL URI as identifier. > >> In practice your assumption is probably right for "normal" URIs, of the >> sort that someone might put in a vcard or on a real business card. >> These things are more likely to arise when the URI is learned through >> signaling, such as in a Contact address. >> >> For instance these can arise as GRUUs. (And yes, there are now some >> implementations of GRUU.) > > Yes, but that makes sense when setting the URI as Request URI and so, but I > just mean the URI with identifies a user, this is, the same URI that the user > sets in "From" header or credentials "username" field. The cases where such things will show up in From are fewer than those where it might show up in To. The obvious case for From is when a gruu is being used for anonymity, although in that case the From might just as well be set to sip:anonym...@anonymizer.invalid. And so that may not be a relevant case for you. There is the case where you had called me, and used a gruu for your Contact address. Later I use that contact to establish a separate dialog to you, and so I use it as both the R-URI and the To-URI. Subsequently in that dialog you may send a reINVITE, in which case you will have to use the same URI as your From-URI. I don't know if any of this affects what you are doing. Thanks, Paul ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Any real case of a TEL/SIP URI with parameters as user?
Iñaki Baz Castillo wrote: > Hi, if there any *real* case in any SIP core (i.e: IMS) in which a user could > have a URI with parameters? > > Usually it doesn't occur as any network/provider users have an identifier > like: > - sip:al...@domain.org > - tel:+12345678 > > However I wonder if there is a real case in which users have params in their > identifying uri's as: > - sip:al...@domain.org;param=lalala > - tel:934354;phone-context=mydomain.org > > Note that a TEL URI must include a param ";phone-context" if the TEL number > is > local (so doesn't start by "+") rather than global. > > So, is there any SIP core in which such URI's exist for its users? > Of course "they COULD exist", however I want to know if they *really* exist :) I'm curious why you ask. Are you considering an implementation that cannot support such use? In practice your assumption is probably right for "normal" URIs, of the sort that someone might put in a vcard or on a real business card. These things are more likely to arise when the URI is learned through signaling, such as in a Contact address. For instance these can arise as GRUUs. (And yes, there are now some implementations of GRUU.) Thanks, Paul ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Query related to OPTIONS
sunil.bha...@wipro.com wrote: > Hi, > > Say, UAS doesn't have any endpoint configured and will not be able to handle > calls. In this case, should the UAS send a 4xx response, say 408 timeout, > when it receives OPTIONS request, or is it better to ignore the incoming > OPTIONS request and not send any response to it? Returning no response at all is an *exceedingly* bad choice. It will result in the requester retrying and so take a long time to fail. Almost anything else would be better, but 408 is nearly as bad. You say it is a UAS, but can't handle calls. Do you mean it can't handle calls *now*? (E.g. it is a "pbx" implemented as a B2BUA that may at a later time be able to handle calls when it has some extensions connected.) Or do you mean it will *never* be able to handle calls, suas would be the case for an event server that only handles SUBSCRIBE and NOTIFY?? IMO OPTIONS was specified poorly when it called for returning the same response that an INVITE would, because it doesn't recognize all these kinds of cases. I believe many devices will respond with 200 to OPTIONS regardless of what they would do for an INVITE. So you might consider doing that - returning 200. If you can *never* support INVITE, just omit it from the Allow header. If you really want to return an error, 480 might suit this situation - that is typically what a proxy would return to an invite if there were currently no registrations. Thanks, Paul > Regards, > Sunil > > -Original Message- > From: Iñaki Baz Castillo [mailto:i...@aliax.net] > Sent: Thursday, November 12, 2009 8:03 PM > To: Sunil Bhagat (WT01 - Telecom Equipment) > Cc: sip-implementors@lists.cs.columbia.edu > Subject: Re: [Sip-implementors] Query related to OPTIONS > > 2009/11/12 : >> Hi, >> >> I have a small query regarding OPTIONS method in SIP. >> As per RFC 3261, OPTIONS is used to query a user agent or server about >> its capabilities and discover its current availability. >> >> Say, I have a SIP server which controls several endpoints, but none of >> them is up. Now I receive an OPTIONS message from the NETWORK. >> So, what should the reply from my server be? Should the SIP server send >> 200 OK response with its capabilities and availability? Or should it >> send some 4XX or 6XX response indicating that endpoints are down? > > I would suggest you to forget the theoretical usage of OPTIONS as it's > not a robust "feature" (imagine there is parallel forking so you just > receive the response from one of the branches). > > However the behavior you mean is more designed to work with endpoints. > This is, I send an OPTIONS to a phone and it replies me 200 if it's > available to receive an INVITE, 486 if it has all its lines in use, > 480 if it has set DND and so... > > But I don't expect the same behaviour in a server/b2bua/gateway as the > server/b2bua/gateway cannot know which response it will receive when > forwarding a call. > > IMHO nowadays OPTIONS is just used to mantain the NAT keepalive and to > check if a server/endpoint is alive (regardless of the response it > replies for that OPTIONS). > > > ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Clarification of Redirect originator
Aniruddha Vaidya wrote: > Hi, > > I have a doubt on this. Should this behavior be of stateful proxy or can > stateless proxy also do this? In my understanding, a stateless proxy should > not do anything on its own and it should actually pass it to UAC. Is this > understanding correct or stateless proxies can also do this? In order to fork a request a proxy must be (transaction)stateful. So you are right that a stateless proxy would have to simply forward the 3xx. Paul > Thanks, > Aniruddha > > -Original Message- > From: sip-implementors-boun...@lists.cs.columbia.edu > [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Brett > Tate > Sent: Wednesday, November 25, 2009 4:29 AM > To: Brez Borland; sip-implementors@lists.cs.columbia.edu > Subject: Re: [Sip-implementors] Clarification of Redirect originator > > See 3xx discussions within rfc3261 section 16.7. The 3xx can be proxied or > the proxy can recurse on the targets from the 3xx's Contact entries. When > doing the recursion, the proxy is still acting as a proxy; it is just > forking the request to more locations. > >> -Original Message- >> From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip- >> implementors-boun...@lists.cs.columbia.edu] On Behalf Of Brez Borland >> Sent: Tuesday, November 24, 2009 4:33 PM >> To: sip-implementors@lists.cs.columbia.edu >> Subject: [Sip-implementors] Clarification of Redirect originator >> >> Hi all, >> >> If I have UAC who is sending a REGISTER request trough proxy server. >> Proxy server sends this request further on to REGISTER server. >> REGISTER server sends a Redirect response to the proxy server. >> >> Now, should proxy server send this Redirect response to UAC, or should >> it try to send the REGISTER request to the address specified in >> Redirect? >> >> The RFC3261, 8.3 Redirect servers, say: >> >> >> When the originator of the >>request receives the redirection, it will send a new request based >> on >>the URI(s) it has received. By propagating URIs from the core of >> the >>network to its edges, redirection allows for considerable network >>scalability. >> >> >> My question is, can the proxy be considered as a request originator? >> Or is it strictly UAC. >> >> I am trying to solve this puzzle and fail to do it myself, please >> gurus of sip, I will greatly appreciate your help, >> >> >> Thank you, >> >> Regards, >> >> Brez >> ___ >> 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 > > ___ > 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] New offer answer using ReInvite and Update
Mayank Gupta wrote: > Hi Ritul > > Is there any significance of this additional message for INVITE? > > ACK for initial INVITE request makes sense as it may be useful for > offer-answer when initial INVITE is without SDP and offer is received from > called party in 200 OK. In that case ACK will send the answer. > > But what is the use of ACK for re-Invite message? The main reason for ACK (IIUC) is because the INVITE can be pending for a long time, unlike other transactions. (The lifetime of the INVITE transaction can be extended indefinitely by sending provisional responses.) Once UAC receives a provisional response, it ceases retransmission of the INVITE. As a consequence, if the 200 response is lost, there will be no retransmission of the INVITE to remind the UAS to retransmit the 200. In lieu of that, the 200 is retransmitted until the ACK is received. Even a reINVITE can result in alerting, and hence may be extended a long time. So the same logic applies there. If you do an O/A using UPDATE, then it really is infeasible for the UAS to alert before responding, so it must make its decision without human input. Thanks, Paul > Mayank > > On Fri, Nov 20, 2009 at 3:41 PM, Ritul Sonania wrote: > >>> Hi All >>> >>> I have a query regarding new offer-answer using Re-invite and Update >>> methods. >>> >>> When a new offer is sent using a Re-invite, it is responded by 200 OK and >>> then ACK for this 200 OK is sent. >>> >>> >Re-Invite (for new offer) >>> <--- 200 OK >>> >ACK >>> >>> However, if a new offer is sent using an UPDATE method, there is no ACK >>> sent. >>> >>> -> UPDATE (for new offer) >>> <- 200 OK >>> >>> My query is why there is no ACK sent for the 200 OK for update message. >> ACK is only sent for INVITE request. >> >> Regards, >> Ritul Sonania >> Niksun >> >>> Mayank >>> ___ >>> 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 > ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] REGISTER request, connection termination
Brez Borland wrote: > Hi all, > > Below I assume using tcp transport for registrations. > > As I understand, while using a reliable transport for dialogs the > connection between UAC and the next hop is active until the dialog is > terminated by one party sending BYE and another party responding back. > The connections on both sides are then closed. You can't assume that. Iñaki pointed you to the "outbound" and "connection reuse" stuff. Aside from that, the best you can expect is that you open a TCP connection to some destination when you want to send a request, and you may receive the responses to that request on the same connection. Then, if you wish you may send additional requests to the same destination over the same connection. But requests to you, even in the same dialog will come over a different connection initiated from the other end, and you will be responding to those, preferably over the same connection. Thanks, Paul ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] The way to reuse TCP Server connection
Victor Pascual Avila wrote: > On Tue, Oct 13, 2009 at 11:12 AM, Jin-Soo Eo wrote: >> Hello, >> >> I would like to know how to reuse Server Connection other than >> mentioned in draft-ietf-sip-connect-reuse-03. >> I think most SIP entities do not support draft-ietf-sip-connect-reuse-03 as a >> way of server connection reuse. >> So, they seem to have implemented their own soultion for server connection >> reuse. >> >> Is there any industry standard? > > Please note that the connection reuse draft was spitted into two > pieces: while [1] is predicated on secure TLS mutual authentication, > [2] specifies connection reuse for SIP over plain TCP and SCTP. > > [1] http://tools.ietf.org/html/draft-ietf-sip-connect-reuse-14 > [2] > http://tools.ietf.org/html/draft-jain-sip-transport-layer-connection-reuse-00 To amplify: One reason use may be limited is precisely because these things are still drafts, not yet RFCs. Also the use of [1] is of course limited to those that want to, and can, use TLS. And [2] is still being significantly debated. The reuse of TCP (or SCTP) connections *bidirectionally* has major security concerns. Its quite likely that proprietary solutions that do it have potential security problems, or else have limited applicability. The most straightforward connection reuse for TCP is simply to maintain separate connections for each direction. It really requires no special draft to tell you how to do that. Thanks, Paul ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] how is answering machine detection handled in SIP ?
David Benoit wrote: > On Fri, Oct 02, 2009 at 04:22:55PM -0400, Dale Worley wrote: >> On Thu, 2009-10-01 at 10:37 +0200, DE CLERCQ Johan wrote: >>> As we all know, in ISDN you can detect when you go to a voicemailbox of >>> a cellular line by looking for the PROGRES message as defined in Q.931. >> There is no good way to do this in SIP. However, an answering automaton >> "should" identify itself with the "automata" media feature tag on its >> Contact header: >> >> Contact: ;automata That would be indication of any sort of automaton. If you want to know it is really a VM server, you would be looking for: Contact: ;automata;actor="msg-taker" (Again, see 3840) (Its "msg-taker" to cover recording of media other than audio.) But I suspect there are a lot of VM systems that don't signal this. Thanks, Paul >> See RFC 3840. > > Even the inclusion of this tag isn't fool proof. Consider the case of user > with voicemail screening. The call is initially directed to an automata but a > human listening in to the recording decides to take the call. A human has > answered, but some filtering was applied. Or a caller interrogation service > that collects information about the caller for users who refuse calls from > private numbers. This would also be initially answered by an automata, but > could ultimately be answered by a human. > > If you are solely looking for whether you were directed to voicemail, I would > look more into the diversion headers and the information you get there. They > will tell you the reason the call was forwarded where it was going before. > Have a look at http://tools.ietf.org/html/draft-levy-sip-diversion-10 > > David > ___ > 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] [Sip-Implementors] DTMF using SIP INFO
To elaborate: There is no standard for DTMF over INFO. The usages that exist in the wild are *proprietary* though you may find some commonality. If you need to use this to interoperate with something, do whatever your peer expects. Thanks, Paul Avasarala Ranjit-A20990 wrote: > Hi > > INFO method is defined in RFC 2976. But yes "dtmf" and "dtmf-relay" are > not standard defined mime types. No there is no registered MIME type for > DTMF. > > > Regards > Ranjit > > -Original Message- > From: sip-implementors-boun...@lists.cs.columbia.edu > [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of > Shefali Dutta > Sent: Tuesday, September 15, 2009 4:28 PM > To: Rohit Aggarwal > Cc: sip-implementors@lists.cs.columbia.edu > Subject: Re: [Sip-implementors] [Sip-Implementors] DTMF using SIP INFO > > Hi, > Thanks for your reply. > > The link below gives two MIME types application/dtmf and > application/dtmf-relay but additionally gives the Note -> > > "Note: dtmf-relay or dtmf are not yet IANA registered application mime > types" > > Is there some other registered MIME type for DTMF? > > Rgds, > Shefali > > -Original Message- > From: Rohit Aggarwal > Sent: Tuesday, September 15, 2009 3:29 PM > To: Shefali Dutta > Subject: RE: [Sip-Implementors] DTMF using SIP INFO > > Hi Shefali > > Checkout > http://www.voip-info.org/wiki/view/SIP+Info+DTMF > > Regards > Rohit Aggarwal > > -Original Message- > From: sip-implementors-boun...@lists.cs.columbia.edu > [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of > Shefali Dutta > Sent: Tuesday, September 15, 2009 3:25 PM > To: sip-implementors@lists.cs.columbia.edu > Subject: [Sip-implementors] [Sip-Implementors] DTMF using SIP INFO > > Hi All, > How DTMF is carried using SIP INFO method? I found some examples using > Content type application/dtmf and application/dtmf-relay. Which is the > reference RFC for these content types? > > Rgds, > Shefali > > > > "DISCLAIMER: This message is proprietary to Aricent and is intended > solely for the use of the individual to whom it is addressed. It may > contain privileged or confidential information and should not be > circulated or used for any purpose other than for what it is intended. > If you have received this message in error,please notify the originator > immediately. If you are not the intended recipient, you are notified > that you are strictly prohibited from using, copying, altering, or > disclosing the contents of this message. Aricent accepts no > responsibility for loss or damage arising from the use of the > information transmitted by this email including damage from virus." > ___ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > "DISCLAIMER: This message is proprietary to Aricent and is intended > solely for the use of the individual to whom it is addressed. It may > contain privileged or confidential information and should not be > circulated or used for any purpose other than for what it is intended. > If you have received this message in error,please notify the originator > immediately. If you are not the intended recipient, you are notified > that you are strictly prohibited from using, copying, altering, or > disclosing the contents of this message. Aricent accepts no > responsibility for loss or damage arising from the use of the > information transmitted by this email including damage from virus." > > ___ > 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 > ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Carets encasing URIs.
Alex Balashov wrote: > I cannot easily tell from 3261 whether references to URIs other than the > Request URI must be encased in "<" and ">" or not, probably because I do > not know how to read BNF. If you are involved in SIP, or almost any IETF protocol, then I strongly suggest that you *learn* to read ABNF. RFC 5234 should tell you all you need to know. Thanks, Paul > In other words, in the absence of a display name (which would be a > quoted string), is this valid? > > Contact: sip:xx.xxx.xx.xxx:5060 > > What about this? > > To: sip:xx.xxx.xxx.xxx:5060 > > I was under the impression it was not, but this is mainly because I've > never seen any implementation NOT use that notation regardless of > whether it is necessary. I do not know if the rules here are more or > less strict than RFC 2822. > > Thanks! > ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Implicit de-registration failure
krishna chaitanya wrote: > Hi All, > > I have question regarding implicit de-registration. This isn't the ideal place to ask this question. Implicit registration is not part of any ietf standard, its a creation of IMS. > 2 IMPUs belonging to same IRS( Implicit registration set) are registered > from two end points. I'm not certain I understand. Is the following what you mean? - IMPU is a UA? Or an AOR? Since you mention end points too, I'll assume an IMPU is an AOR. - AORs X, Y, and Z are part of the same IRS, so that if X is registered then Y and Z are implicitly registered; if Y is registered then X and Z are implicitly registered. - You have one UA that registers X - You have another UA that also registers X (or Y or Z) > when first IMPU is registered all the IMPU's belonging to IRS are > implcitly registered. ok. So AOR X was registered by UA-A, and Y and Z are also implicitly registered to UA-A. You don't mention it, but I will also assume that then UA-B registers AOR-X and so Y and Z are also implicitly registered for it. At that point there are effectively *six* registrations active. I would see all six in a notification by the reg event package. > and then the second IMPU is involved in a active session OK, lets assume that somebody called AOR Y and it was answered by UA-A. > and finally when the first IMPU is de-registered then the second IMPU > is still registered and the is still ongoing without any call release. Now, why is it that any deregistration is going on? Is it an active request? Or just an expiration of a registration that hasn't been refreshed? If so, why wasn't it refreshed? And is it a deregistration by UA-A or UA-B? AFAIK IMS doesn't allow a session to continue after deregistration. It will terminate it. > Observation 1: In 200 OK message for the second register request I see 2 > contact headers belonging to 2 IMPU's. By 2nd register request you mean the one by UA-B? The response to a register request will contain all the Contact addresses that have been registered for the same AOR. Assuming an IMPU is an AOR. In your scenario these should be for the two different UAs that have registered. > Observation 2: when the first IMPU is de-registered from one end point. then > i see a 200OK for that de-register message along with the contact header > related to the second IMPU. I guess you are talking about explicit deregistration - something sending an explicit register request to an AOR with a Contact that was previously registered and and expiration time of 0. In that case, the response to that request should contain any other contacts for the same AOR that are still registered. So if both UA-A and UA-B had registered X, and now UA-A is deregistering X, then the response should include a Contact containing the URI of UA-B. > Here the implicit de-registration is not happening and as per 3GPP 24228 > 5.2.1a > When one of the Public User Identities within the set is de-registered, all > Public User Identities that have been implicitly registered are de-registered > at > the same time. It sounds to me like you are mixing up AORs and UA identities / Contact addresses. > But In this case below here is what happening due to the same 3GPP 24228 > 5.2.1a para > > Registration and de-registration always relates to a particular contact > address > and a particular Private User Identity. A Public user identity that has been > registered (including when implicitly registered) with different contact > addresses remains registered in relation to those contact > addresses that have not > been de-registered. > So when first IMPU is registered all the IMPU's belonging to IRS are > implcitly registerd. when the second IMPU is involved in a active session and > when the first IMPU is de-registered then the second IMPU is still registered > and the is still ongoing without any call release. I don't understand the point you are trying to make. > Is this a conflict within 3GPP ?? > what should be behaviour in this case when one IMPU belonging to an IRS set > is deregistered?? > > Should the de-registration of second IMPU or all other IMPU's be not > de-regisrered?? > Any reference to 3GPP or ETSI is available to resolve this issue?? I think the conflict is probably in your understanding, not the spec. You will have much better luck talking about this *here* if you translate everything from IMS terminology to SIP terminology. It may also help you to understand it. Thanks, Paul > Does anybody aware of the real implemention regarding this?? > > I highly appreciate for your comments and suggestions. > > Kind Regards, > Krishna. > > > > > > ___ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > ___ Sip-implementors mailing li
Re: [Sip-implementors] Question on multiple INFO messages
Yong Xin wrote: > Hi, > > The RFC3261 is clear that UA can not send a re-INVITE when another > INVITE is pending. However, for non-INVITE request (e.g.: INFO), I was > not able to find any restriction like this. So I assume this is allowed. > > However, sending another INFO before the previous one has been answered > can cause problem when UDP packet is deliveried out-of-order. Here is an > example: > > - INFO (cseq=1) is lost due to network issue > - INFO (cseq=2) is received and processed by the server > - retranmission of INFO (cseq=1) arrives at server which replies with > 500 error, because the cseq number is lower than the last cseq number on > the dialog > > I'm wondering what is the right solution for this: > > 1) Should we switch to use TCP as the transport protocol so that the > order of the packet delivery is guaranteed? Switching to TCP *won't* guarantee the order of delivery if there are any intermediate nodes in the path. > 2) Should UAC send INFO messages in sequence (i.e.: not start a new one > until previous one is final responded)? I haven't seen this discussed with respect to INFO, but issues are much the same as NOTIFY. Bottom line is that in general you should wait, only sending one at a time. In certain special cases it may make sense not to wait. Notably if the new message preempts the prior one, so it doesn't matter if the prior one gets processed or not. Thanks, Paul > Thanks, > Yong > > > ___ > 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] [Sip] 200 OK response for hold with different media capabilities
I'm removing the cross posting to the sip list. Cross posting is unpolite to those who subscribe to both lists. And this topic is appropriate to sip-implementors. Avasarala Ranjit-A20990 wrote: > Hi Paul > > The HOLD request is nothing but a re INVITE request indicating HOLD. There is no such thing as a reINVITE request that indicates *HOLD*. There are indications for sendrecv, sendonly, recvonly, and inactive. They are often used by UAs that have a HOLD feature, but they are also used for other purposes unrelated to HOLD features. When a UAC implements a HOLD feature by sending a reINVITE with a=sendonly, the UAS does not know that the reason for this change is because of a HOLD feature. It can only take the signaling at face value: "My peer wants to send me media, but doesn't want to receive it. Given that constraint, what do I want to do?" There can be many answers to that question. There are no rules that say: thou shalt not change media attributes in this case. > Could you give a use case where such a thing may happen? I have not come > across any scenario where in the process of putting remote party on > HOLD, media parameters like IP/codec getting changed. If this happens, > then it cannot be considered a HOLD request. Its probably good advice that in general when being presented with an offered change you should respond with an answer that makes the minimal changes on your part that are consistent with what was offered. But that behavior isn't required. I have heard of implementations that change media port on every reINVITE. Doesn't make sense to me, but maybe it did to them, and its within the rights of the implementor to do so. > So how do u distinguish a HOLD request from a non HOLD one if in both > the cases the media parameters (other than a=.) change? As the recipient, you *don't* distinguish a HOLD request from a non HOLD one. You simply take things at face value without attempting to ascribe a reason for *why* they have happened. Thanks, Paul > Regards > Ranjit > > -Original Message- > From: Paul Kyzivat [mailto:pkyzi...@cisco.com] > Sent: Tuesday, August 25, 2009 12:07 AM > To: Avasarala Ranjit-A20990 > Cc: sunil.bha...@wipro.com; s...@ietf.org; > sip-implementors@lists.cs.columbia.edu; s...@core3.amsl.com > Subject: Re: [Sip-implementors] [Sip] 200 OK response for hold with > different media capabilities > > > > Avasarala Ranjit-A20990 wrote: >> no it should not. For a Hold request, you do not send any media >> capabilities. U only change the existing media description lines to >> indicate HOLD. > > I beg to differ. > > Technically there is no HOLD request. > All there is is an offer that offers to change a media attribute, from > sendrecv to sendonly or inactive, or from sendonly or recvonly to > inactive. > > The response may change anything that is permitted to be changed in the > answer, given the offer. So it may not add m-lines, but it can certainly > change media addresses, and within limits may change media formats > (codecs). > > Thanks, > Paul > >> Regards >> Ranjit >> >> >> >> >> >> From: sip-boun...@ietf.org [mailto:sip-boun...@ietf.org] On Behalf Of >> sunil.bha...@wipro.com >> Sent: Monday, August 24, 2009 3:25 PM >> To: s...@ietf.org; sip-implementors@lists.cs.columbia.edu; >> s...@core3.amsl.com >> Subject: [Sip] 200 OK response for hold with different media >> capabilities >> >> >> >> Hi All, >> >> >> >> I have a small query related to HOLD request being sent out. >> >> >> >> For a hold request, can gateway respond with different media >> capabilities in 200 OK response? >> >> >> >> Is the HOLD treated as any normal Re-INVITE? >> >> >> >> Regards, >> >> Sunil. >> >> >> >> Please do not print this email unless it is absolutely necessary. >> >> The information contained in this electronic message and any >> attachments to this message are intended for the exclusive use of the >> addressee(s) and may contain proprietary, confidential or privileged >> information. If you are not the intended recipient, you should not >> disseminate, distribute or copy this e-mail. Please notify the sender >> immediately and destroy all copies of this message and any > attachments. >> WARNING: Computer viruses can be transmitted via email. The recipient >> should check this email and any attachments for the presence of > viruses. >> The company accepts no liability for any damage caused by any virus >> transmitted by this email. >> >> www.wipro.com >> >> ___ >> 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] [Sip] 200 OK response for hold with different media capabilities
Avasarala Ranjit-A20990 wrote: > no it should not. For a Hold request, you do not send any media > capabilities. U only change the existing media description lines to > indicate HOLD. I beg to differ. Technically there is no HOLD request. All there is is an offer that offers to change a media attribute, from sendrecv to sendonly or inactive, or from sendonly or recvonly to inactive. The response may change anything that is permitted to be changed in the answer, given the offer. So it may not add m-lines, but it can certainly change media addresses, and within limits may change media formats (codecs). Thanks, Paul > Regards > Ranjit > > > > > > From: sip-boun...@ietf.org [mailto:sip-boun...@ietf.org] On Behalf Of > sunil.bha...@wipro.com > Sent: Monday, August 24, 2009 3:25 PM > To: s...@ietf.org; sip-implementors@lists.cs.columbia.edu; > s...@core3.amsl.com > Subject: [Sip] 200 OK response for hold with different media > capabilities > > > > Hi All, > > > > I have a small query related to HOLD request being sent out. > > > > For a hold request, can gateway respond with different media > capabilities in 200 OK response? > > > > Is the HOLD treated as any normal Re-INVITE? > > > > Regards, > > Sunil. > > > > Please do not print this email unless it is absolutely necessary. > > The information contained in this electronic message and any attachments > to this message are intended for the exclusive use of the addressee(s) > and may contain proprietary, confidential or privileged information. If > you are not the intended recipient, you should not disseminate, > distribute or copy this e-mail. Please notify the sender immediately and > destroy all copies of this message and any attachments. > > WARNING: Computer viruses can be transmitted via email. The recipient > should check this email and any attachments for the presence of viruses. > The company accepts no liability for any damage caused by any virus > transmitted by this email. > > www.wipro.com > > ___ > 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] Can EP send media only peer supports
OKUMURA Shinji wrote:
> Hi Mr. Kyzivat,
Please, lets not be formal. Call me Paul. :-)
> If the direction of the answer is "recvonly" or "inactive", it is
> no problem that the answerer adds new codec. But if the direction
> is "sendrecv" ("sendonly" is certainly not allowed), the added
> codec is "implicit-recvonly".
I guess that is a good way to think of it.
> The offerer MAY send the added codec to the answerer.
I guess you mean the offerer may send media encoded using the added
codec to the answerer. I agree.
> But this
> negotiated state is very brittle. IMO it will not be able to
> endure reINVITE. Because the answerer can not indicate the added
> codec in new offer, unless it determine the change.
I don't understand you here.
A reinvite may result in an o/a with the offerer and answerer being the
same as before, or it may result in them being reversed from before. But
either way, the new codec may be included in either the offer or answer.
If in the new reinvite, the o2 is by the same offerer as o1, then it may
include the added codec. The presence of the codec in a1 may have
suggested that it would be useful to include it in o2. Of course o2 may
also *not* include the codec. That can set up a replay of the earlier
o/a exchange.
If in the new reinvite, the o2 is by the earlier answerer, then of
course it may include the added codec. This isn't required, but it would
be a natural thing to do. In that case the other end will have the
opportunity to refuse at codec.
> I think this is a problem for RFC3264.
> What do you think about this reINVITE ?
I'm not seeing what the problem is.
Thanks,
Paul
> Regards,
> Shinji
>
> Paul Kyzivat
>> Rockson Li (zhengyli) wrote:
>>> Paul,
>>>
>>> If I catch you clearly, do you mean this is a real bug in RFC3264?
>> IMO this is unclear. It might be that what is written is not exactly
>> what the original authors intended. Or maybe it is as intended but isn't
>> what people now wish had been written.
>>
>> Either way it isn't necessarily a bug if what is written can be
>> implemented, which seems to be the case.
>>
>>> Do we have some formal doc/draft to clarify usage here?
>> I don't think so.
>>
>> At this point any change in the specs is likely to disrupt somebody's
>> implementation, so things must be done carefully.
>>
>> If it is considered that there is ambiguity about how this should be
>> implemented, then a clarification would be a good thing. But it will
>> then take some work to decide which of the possible interpretations
>> should be blessed.
>>
>> I'd be interested to hear what is implemented in practice - perhaps
>> stats from SipIt.
>>
>> Thanks,
>> Paul
>>
>>> Thanks
>>> Regards,
>>> -Rockson
>>> -Original Message-
>>> From: Paul Kyzivat (pkyzivat)
>>> Sent: Saturday, August 15, 2009 7:54 AM
>>> To: Dale Worley
>>> Cc: Rockson Li (zhengyli); sip-implementors@lists.cs.columbia.edu
>>> Subject: Re: [Sip-implementors] Can EP send media only peer supports
>>>
>>> comment at end.
>>>
>>> Dale Worley wrote:
>>>> On Fri, 2009-08-14 at 14:41 +0800, Rockson Li (zhengyli) wrote:
>>>>> I think answerer can add additional codec G729 here per sec 6.1 of
>>>>> rfc3264
>>>>>
>>>>>
>>>>>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
>>>>>
>>>>>
>>>>> However, here comes the inconsistency.
>>>>>
>>>>> When answerer send media, it cannot send G723 packets to offerer per
>>>>> sec
>>>>> 6.1 of RFC3264
>>>>>
>>>>>
>>>>> The answerer MUST send using a media format in the offer
>>>>>that is also listed in the answer,
>>>>>
>>>>> Whereas RFC3264 does not forbid offerer to send G729 packets to
>>>>> answerer per sec 7
>>>>>
>>>>>
>>>>> It MUST send using a media format listed in the answer, and it
>>>>> ***SHOULD*** use the first media format listed in the answer when it
>>>>>does send.
>>>>>
>>>> I think you've found a mistake in the wording of the RFC. The writers
>>>> assumed that if
Re: [Sip-implementors] Can EP send media only peer supports
T Satyanarayana-A12694 wrote: > Yes, I do agree that implementations have done a good job of working > with this ambiguity so far. And, it is not as much an issue. > > However, I am having a difficulty to visualize a use case where the > offerer may use this "addl codec" to send media. Even if the offerer is > prepared to receive, the offerer would probably never use it (if he > could, he would have declared it in offer anyway). > > So, wouldn't it help if we can add a qualifying statement to the spec: To *what* spec? 3264? It perhaps could have gone in the offeranswer draft, but that is "finished" except for a little tidying up. Thanks, Paul > "The answerer may add additional codecs in the answer. However, at the > time of writing this spec, there are no known use cases warranting this > condition." > Regards > Satya T > > -Original Message- > From: Paul Kyzivat [mailto:pkyzi...@cisco.com] > Sent: Tuesday, August 18, 2009 7:53 PM > To: T Satyanarayana-A12694 > Cc: Dale Worley; sip-implementors@lists.cs.columbia.edu > Subject: Re: [Sip-implementors] Can EP send media only peer supports > > The more I think about this "issue" the less I understand why it should > be an issue. > > The answerer is under no obligation to include codecs that were not > present in the offer. And if it does so, there is no guarantee of > circumstances under which they might be used. And the offerer is > certainly free to ignore them. > > So the only question is: > > *If* the answer includes codecs that were not included in the offer, may > the offerer use them to encode media? And that is only an issue if the > answerer is *not* expecting them to be used. > > So, if you are constructing an answer, don't include any codecs that you > aren't prepared to receive now. (If it hurts, don't do it.) > > All we could possibly do by tightening up the wording is ensure that > even if mentioned, such codecs would not be used. What purpose would > that serve? And such restriction would only apply if both parties adhere > to it. > > Thanks, > Paul > > T Satyanarayana-A12694 wrote: >> >> >> -Original Message- >> From: Dale Worley [mailto:dwor...@nortel.com] >> Sent: Tuesday, August 18, 2009 1:37 AM >> To: T Satyanarayana-A12694 >> Cc: Paul Kyzivat; sip-implementors@lists.cs.columbia.edu >> Subject: RE: [Sip-implementors] Can EP send media only peer supports >> >> On Sat, 2009-08-15 at 23:35 +0800, T Satyanarayana-A12694 wrote: >>> Additional round trips should be made optional (only for >>> implementations having concurrent codecs limitation). >>> >>> Additionally, why can't the spec be modified (or place in a BCP): >>> 1. to allow only a sub-set (of what is present in the offer) in the >>> answer (or even just one codec) >>>> If you mean, "Is it allowed to put in the answer only a subset of >>>> the >> codecs that are in the offer", that is allowed now. >> >> No, I mean "Answerer must include only a sub-set of codecs present in >> the offer". Or "Answerer must not include any codec not present in the > >> offer". >> >>> 2. to place a restrion on the offerer to only use one of the codecs >>> listed in the intersection of answer & offer. >> Some implementations use more than one codec, so that would have to be > >> considered a BCP. >> >> 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] Require header in ACK
soma bhargava wrote: > Hi All, > > As per RFC 3261 > sec 8.2.2.3 Require: > An ACK request for a 2xx response MUST contain only those Require > and Proxy-Require values that were present in the initial request. I think that is less than ideal wording. It would have been better worded as: "An ACK request for a 2xx response MUST NOT contain any Require or Proxy-Require values that were not present in the initial request." There is no purpose to Require or Proxy-Require in ACK. Including Require values that were not present in the INVITE is an invitation for the ACK to be rejected, which it should not be. In practice you would be best to include *no* Require or Proxy-Require values in the ACK regardless of what ones were included in the INVITE. Thanks, Paul > and as per section 20 of RFC3261: > > Header field where proxy ACK BYE CAN INV OPT REG > Require ar - c - c c c > > As per RFC 3262 > sec 4 UAC Behavior: > A Require header with the value 100rel MUST NOT be present in > any requests excepting INVITE, although extensions to SIP may allow its > usage with other request methods. > > the above 3 statements contradicts each other. > Please suggest if we need to add require header in ACK or not? > If yes then should it contain 100rel or not? > > Regards, > Soma > > ___ > 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] Can EP send media only peer supports
The more I think about this "issue" the less I understand why it should be an issue. The answerer is under no obligation to include codecs that were not present in the offer. And if it does so, there is no guarantee of circumstances under which they might be used. And the offerer is certainly free to ignore them. So the only question is: *If* the answer includes codecs that were not included in the offer, may the offerer use them to encode media? And that is only an issue if the answerer is *not* expecting them to be used. So, if you are constructing an answer, don't include any codecs that you aren't prepared to receive now. (If it hurts, don't do it.) All we could possibly do by tightening up the wording is ensure that even if mentioned, such codecs would not be used. What purpose would that serve? And such restriction would only apply if both parties adhere to it. Thanks, Paul T Satyanarayana-A12694 wrote: > > > -Original Message- > From: Dale Worley [mailto:dwor...@nortel.com] > Sent: Tuesday, August 18, 2009 1:37 AM > To: T Satyanarayana-A12694 > Cc: Paul Kyzivat; sip-implementors@lists.cs.columbia.edu > Subject: RE: [Sip-implementors] Can EP send media only peer supports > > On Sat, 2009-08-15 at 23:35 +0800, T Satyanarayana-A12694 wrote: >> Additional round trips should be made optional (only for >> implementations having concurrent codecs limitation). >> >> Additionally, why can't the spec be modified (or place in a BCP): >> 1. to allow only a sub-set (of what is present in the offer) in the >> answer (or even just one codec) > >>> If you mean, "Is it allowed to put in the answer only a subset of the > codecs that are in the offer", that is allowed now. > > No, I mean "Answerer must include only a sub-set of codecs present in > the offer". Or "Answerer must not include any codec not present in the > offer". > >> 2. to place a restrion on the offerer to only use one of the codecs >> listed in the intersection of answer & offer. > > Some implementations use more than one codec, so that would have to be > considered a BCP. > > Dale > > > ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Can EP send media only peer supports
Dale Worley wrote: > On Sat, 2009-08-15 at 23:35 +0800, T Satyanarayana-A12694 wrote: >> Additional round trips should be made optional (only for implementations >> having concurrent codecs limitation). >> >> Additionally, why can't the spec be modified (or place in a BCP): >> 1. to allow only a sub-set (of what is present in the offer) in the >> answer (or even just one codec) > > If you mean, "Is it allowed to put in the answer only a subset of the > codecs that are in the offer", that is allowed now. > >> 2. to place a restrion on the offerer to only use one of the codecs >> listed in the intersection of answer & offer. > > Some implementations use more than one codec, so that would have to be > considered a BCP. Note that Telepone-Events (DTMF) is simply represented as another codec, so even implementations that support only one "real" codec at a time are likely two support a real one plus telephone events. Who is to say that there aren't other "special" codecs like this? So I think you must actually consider this sort of restriction as a restriction to certain *combinations* of codecs. It doesn't even sound like a BCP, in that it isn't *best* for everybody. Its just least common denominator - or a profile of usage. But if there are implementations that have such a restriction, and have good cause not to remove it, then it would be good to have a way to signal such limitation. One way I have heard of doing this with current mechanisms is to initially offer several codecs, but with a=inactive. Then, after the first answer is received, offer a single codec with a=sendrecv. Thanks, Paul ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Significance of History info in 18x response
Bhaskar Dutta wrote: >> I had a doubt on History-info header present in Sip 18x Responses. >> >> Are the History-info headers UAC received in 18x response useful to an >> application or user ? >> >> If yes can you please quote an example where its useful to an >> application/user . This is entirely hypothetical: If the UAC has multiple early dialogs established, it *could* use the H-I info to decide which ones to prefer. It could send BYE to some it doesn't prefer (e.g. those that were forwarded if there is one that wasn't forwarded), or it might use similar preferences to decide which early media to render. But I will be first to admit that is pretty far fetched. Thanks, Paul >> How should the UAC's treat these HI headers? >> >> Thanks, >> Divya. > > RFC 4244 Section 4.3.1. User Agent Client (UAC) Behavior > >With the exception of the processing of a 3xx response described >above, the processing of the History-Info header received in the >Response is application specific and outside the scope of this >document. However, the validity of the information SHOULD be ensured >prior to any application usage. For example, the entries MAY be >evaluated to determine gaps in indices, which could indicate that an >entry has been maliciously removed or removed for privacy reasons. >Either way, an application MAY want to be aware of potentially >missing information. > > The original draft (draft-ietf-sip-history-info-00) talked about 183 > responses, this was removed in the subsequent versions: > >2.3.3.2 Processing History-Info in Responses > >A proxy that receives a Request with the HistInfo option tag in the >Supported header, and depending upon a local policy supporting the >capture of History-Info, SHOULD return captured History-Info in >subsequent, provisional and final responses to the Request. A 183 >response MAY be sent explicitly for the purposes of conveying >History-Info prior to the final response. > > Regards, > Bhaskar > > ___ > 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] Can EP send media only peer supports
Rockson Li (zhengyli) wrote: > Paul, > > If I catch you clearly, do you mean this is a real bug in RFC3264? IMO this is unclear. It might be that what is written is not exactly what the original authors intended. Or maybe it is as intended but isn't what people now wish had been written. Either way it isn't necessarily a bug if what is written can be implemented, which seems to be the case. > Do we have some formal doc/draft to clarify usage here? I don't think so. At this point any change in the specs is likely to disrupt somebody's implementation, so things must be done carefully. If it is considered that there is ambiguity about how this should be implemented, then a clarification would be a good thing. But it will then take some work to decide which of the possible interpretations should be blessed. I'd be interested to hear what is implemented in practice - perhaps stats from SipIt. Thanks, Paul > Thanks > Regards, > -Rockson > -Original Message- > From: Paul Kyzivat (pkyzivat) > Sent: Saturday, August 15, 2009 7:54 AM > To: Dale Worley > Cc: Rockson Li (zhengyli); sip-implementors@lists.cs.columbia.edu > Subject: Re: [Sip-implementors] Can EP send media only peer supports > > comment at end. > > Dale Worley wrote: >> On Fri, 2009-08-14 at 14:41 +0800, Rockson Li (zhengyli) wrote: >>> I think answerer can add additional codec G729 here per sec 6.1 of >>> rfc3264 >>> >>> >>>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 >>> >>> >>> However, here comes the inconsistency. >>> >>> When answerer send media, it cannot send G723 packets to offerer per >>> sec >>> 6.1 of RFC3264 >>> >>> >>> The answerer MUST send using a media format in the offer >>>that is also listed in the answer, >>> >>> Whereas RFC3264 does not forbid offerer to send G729 packets to >>> answerer per sec 7 >>> >>> >>> It MUST send using a media format listed in the answer, and it >>> ***SHOULD*** use the first media format listed in the answer when it >>>does send. >>> >> I think you've found a mistake in the wording of the RFC. The writers > >> assumed that if the offerer was willing to send G729, then it would >> have offered to do so. Clearly, the intention is that both the >> offerer and answerer must use only codecs that have been listed in >> both the offer and the answer. > > I think there was some inconsistency in thinking about whether this is a > *negotiation* or a *declaration*. > > Note that the answerer is permitted to begin sending media to the > offerer as soon as the offer is received. So at that point this is being > considered a declaration, not a negotiation. While the answerer is > obligated to list the codecs it is sending to in the answer, the offerer > doesn't necessarily have the answer when packets arrive. > > But requiring the answer to list the packets the answerer will send to > does turn it into an after-the-fact negotiation. > > Allowing the answer to have new codecs, and the offerer to send to them > is simply symmetry with the answerer being able to use any of the codecs > in the offer. > > My impression is that when this was first done there was a lot of > concern in reducing round trips, so it was only a 2-way handshake rather > than 3-way. In retrospect, it seems that few implement the way it was > apparently intended. Many apparently can't support multiple concurrent > codecs and so need a negotiation to settle on one before media can flow. > > Others have different kinds of restrictions. So it seems a *negotiation* > is really needed, even if it takes more round trips. > > Thanks, > Paul > ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Can EP send media only peer supports
comment at end. Dale Worley wrote: > On Fri, 2009-08-14 at 14:41 +0800, Rockson Li (zhengyli) wrote: >> I think answerer can add additional codec G729 here per sec 6.1 of >> rfc3264 >> >> >>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 >> >> >> However, here comes the inconsistency. >> >> When answerer send media, it cannot send G723 packets to offerer per sec >> 6.1 of RFC3264 >> >> >> The answerer MUST send using a media format in the offer >>that is also listed in the answer, >> >> >> Whereas RFC3264 does not forbid offerer to send G729 packets to answerer >> per sec 7 >> >> >> It MUST send using a media format listed in the answer, >> and it ***SHOULD*** use the first media format listed in the answer when >> it >>does send. >> > > I think you've found a mistake in the wording of the RFC. The writers > assumed that if the offerer was willing to send G729, then it would have > offered to do so. Clearly, the intention is that both the offerer and > answerer must use only codecs that have been listed in both the offer > and the answer. I think there was some inconsistency in thinking about whether this is a *negotiation* or a *declaration*. Note that the answerer is permitted to begin sending media to the offerer as soon as the offer is received. So at that point this is being considered a declaration, not a negotiation. While the answerer is obligated to list the codecs it is sending to in the answer, the offerer doesn't necessarily have the answer when packets arrive. But requiring the answer to list the packets the answerer will send to does turn it into an after-the-fact negotiation. Allowing the answer to have new codecs, and the offerer to send to them is simply symmetry with the answerer being able to use any of the codecs in the offer. My impression is that when this was first done there was a lot of concern in reducing round trips, so it was only a 2-way handshake rather than 3-way. In retrospect, it seems that few implement the way it was apparently intended. Many apparently can't support multiple concurrent codecs and so need a negotiation to settle on one before media can flow. Others have different kinds of restrictions. So it seems a *negotiation* is really needed, even if it takes more round trips. Thanks, Paul ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] 404 for subsequent session refresh request
vijay wrote: > Hi, > > a snippet from 3311: >If a UA receives a non-2xx final response to a UPDATE, he session > parameters MUST remain unchanged, as if no UPDATE had been issued. > Note that, > as stated in Section 12.2.1 of RFC 3261 [1], if the non-2xx final > response is a > 481 (Call/Transaction Does Not Exist), or a 408 (Request Timeout), or no > response at all is received for the UPDATE (that is, a timeout is > returned by > the UPDATE client transaction), the UAC will terminate the dialog. > > > If we receive 404 response for the subsequent session refresh > requests, do we need to terminate the session by sending BYE? > > Please clarify See RFC 5057. The 404 indicates that the dialog itself is gone away. You should send a BYE to be sure, but there is a good chance that it will also fail. Paul ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] SIP OPTIONS
Manoj Priyankara [TG] wrote: > Hi Paul, > Thanks! Hope you are doing well! > > This is not to check whether a particular dialog is alive. But to check > whether the UAS is alive. This might be useful when a particular UAC > such as an IAD wants to know the liveness of the UAS. > > I've seen some SIP ALG's use this method to see the availability of the UAS. Its reasonable for checking general availability of the UA, assuming of course that you know the URI of the UA, rather than just of the AOR. Thanks, Paul > BR, > Manoj > > > -Original Message- > From: Paul Kyzivat [mailto:pkyzi...@cisco.com] > Sent: Sun 8/9/2009 2:48 AM > To: Manoj Priyankara [TG] > Cc: sip-implementors@lists.cs.columbia.edu > Subject: Re: [Sip-implementors] SIP OPTIONS > > > > Manoj Priyankara [TG] wrote: > > Dear All, > > > > According to the RFC 3261, SIP OPRIONS message should be used to query > > the statue of other UAC or the UAS. Is it OK to use the OPTIONS as a > > keep alive message to know whether the UAS is alive? > > > > Is it necessary to send the OPTIONS message from a registered user or is > > it possible to send the OPTIONS message from a general user and get 200- > > OK as the response? > > Its not entirely clear what you want to determine by using OPTIONS. > > Are you looking to verify the liveness of your peer UA in a dialog? > If not, what? > > OPTIONS isn't a good choice for testing the peer in a dialog. > If you send it in-dialog (using the remote target, route set, call ID, > from and to tags of the dialog), then presumably it will follow the path > of dialog. But when it reaches the UAS, according to 3261 it is supposed > to treat the same as an OPTIONS received out of dialog. Its not entirely > clear what that means. It might mean that it could succeed even though > the UA has lost track of the dialog. (Consider for instance that the UA > has rebooted and lost all state.) > > Because the handling is somewhat ambiguous in this case, you can't trust > the results to report what you want to know. > > To test the liveness of your peer in an invite dialog you are better off > to use reINVITE or UPDATE. > > Thanks, > Paul > ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] SIP OPTIONS
Manoj Priyankara [TG] wrote: > Dear All, > > According to the RFC 3261, SIP OPRIONS message should be used to query > the statue of other UAC or the UAS. Is it OK to use the OPTIONS as a > keep alive message to know whether the UAS is alive? > > Is it necessary to send the OPTIONS message from a registered user or is > it possible to send the OPTIONS message from a general user and get 200- > OK as the response? Its not entirely clear what you want to determine by using OPTIONS. Are you looking to verify the liveness of your peer UA in a dialog? If not, what? OPTIONS isn't a good choice for testing the peer in a dialog. If you send it in-dialog (using the remote target, route set, call ID, from and to tags of the dialog), then presumably it will follow the path of dialog. But when it reaches the UAS, according to 3261 it is supposed to treat the same as an OPTIONS received out of dialog. Its not entirely clear what that means. It might mean that it could succeed even though the UA has lost track of the dialog. (Consider for instance that the UA has rebooted and lost all state.) Because the handling is somewhat ambiguous in this case, you can't trust the results to report what you want to know. To test the liveness of your peer in an invite dialog you are better off to use reINVITE or UPDATE. Thanks, Paul ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] 180 Ringing after 183 Session progress
Olle E. Johansson wrote: > 6 aug 2009 kl. 12.49 skrev Vivek Batra: > Greetings, I am wondering if the below scenario is valid or not. <-- 183 (with SDP) then, <-- 180 (without SDP) >>> Yes it's. >>> However it depends in UAC behaviour on how to render it to the human >>> (it could choose to render the early-media comming from the same 183, >>> or it could choose to render internal ringing due to the 180). >> I would suggest stopping the playback of audio when you receive the >> 180 with SDP and revert to the ringing tone. Users does not like >> silence and sending an 180 would suggest that there's no more early >> media to me. >> >> [Vivek] - With some ITSP's, 183 Session Progress is sent (with SDP) >> to play >> the music (something like, please wait while your call is on wait) >> when >> actual called party is busy. However, 180 Ringing is sent as soon as >> call >> has been placed to called party and called party is ringing. >> ITSP does not disconnect the media after sending 180 Ringing instead >> start >> playing Ring Back Tone (RBT) to caller. Hence, in either manner >> while caller >> disconnects the media or not on receipt of 180 Ringing (without >> SDP), RBT >> will be played to caller either locally (if caller honors 180 >> Ringing) or by >> remote server (if caller does not honors 180 Ringing). >> I believe in having a check in application to check whether any RTP >> stream >> is still there or not after receiving 180 Ringing (without SDP). If >> no RTP >> is coming, then only 180 Ringing should be honored to play RBT >> locally else >> RTP from ITSP should be played. >> > That sounds like a good pragmatic approach. > > On a related topic. What should one do in this case? > > <--- 183 with sdp from UA 1 > (10 secs) > <--- 183 with sdp from UA 2 > (5 secs) > <--- 180 ringing from UA 3 > <--- 200 OK from UA 3 > From testing, different devices do very different things. There are many different things that might make sense. The main problem is that you are trying to multiplex three incoming streams into one, and there is no perfect way to do it. You could mix all the streams you are receiving. But that will most likely be terrible. You can stick with one, ignoring the others, until you stop receiving packets from it, then switch to another. If your phone is capable, you might render a display showing all the different calls you have, with buttons to switch the played audio between them. Obviously you want to switch to the one you get the 200 from eventually. But it isn't necessarily obvious which of the streams you are receiving is from UA3. Thanks, Paul > /O :-) > ___ > 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] 180 Ringing after 183 Session progress
I just saw this thread. Thanks Mikael for your response. Its the best
one available for this case, assuming (as the original poster has
confirmed) that this is all one dialog.
If there is early media flowing, you probably don't want to preempt it
with a generated ringback. But if there is no media flowing, then a
generated ringback would probably be a good idea.
But this rendering behavior is largely an implementation issue. If you
do it well then people will like your device. If you do it poorly, then
people won't. And there is plenty of room for innovation, especially
with devices having more capabilities. For instance, you might indicate
the alerting status visually if your device can do that. Or you could
mix a ringback with the incoming audio, though you might have difficulty
finding a way to do that which is acceptable to people.
Thanks,
Paul
Mikael Magnusson wrote:
> On Thu, Aug 06, 2009 at 05:27:10PM +0530, Abhishek Dhammawat wrote:
>> Hi
>>
>> In my opinion RBT(Ring Back Tone) should be played.
>>
>> regards
>> Abhishek Dhammawat
>>
>
> Since nobody has mentioned RFC 3960 I thought it would be appropriate to
> quote a portion of section 3.2[1].
>
>With this in mind, a UAC should develop its local policy regarding
>local ringing generation. For example, a POTS ("Plain Old Telephone
>Service")-like SIP User Agent (UA) could implement the following
>local policy:
>
> 1. Unless a 180 (Ringing) response is received, never generate
> local ringing.
>
> 2. If a 180 (Ringing) has been received but there are no incoming
> media packets, generate local ringing.
>
> 3. If a 180 (Ringing) has been received and there are incoming
> media packets, play them and do not generate local ringing.
>
> Note that a 180 (Ringing) response means that the callee is
> being alerted, and a UAS should send such a response if the
> callee is being alerted, regardless of the status of the early
> media session.
>
> I think 3 above answers the original question about local ringtone
> generation.
>
> /Mikael
>
> [1]http://tools.ietf.org/html/rfc3960#section-3.2
>
>> 2009/8/6 Abhishek Dhammawat
>> mailto:abhishek.dhamma...@aricent.com>>
>> Hi
>>
>> I would request you not to remove the original question from the mail chain
>> for better understanding of the issue I am putting the question by Miguel
>> orielly again
>>
>>
>> "I am wondering if the below scenario is valid or not.
>>
>> <-- 183 (with SDP) then,
>> <-- 180 (without SDP)
> ___
> 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] SIP/2.0 487 LR2 - User not registered on this client
Iñaki Baz Castillo wrote: > 2009/8/4 Dale Worley : >> Some SIP systems will not accept INVITEs from phones that are not >> registered with the system. This is not a requirement of SIP, but it >> appears that your system enforces this requirement. >> >> In regard to the specific "487" response, its purpose is to report that >> the processing of a request was terminated by a CANCEL. So it appears >> that that response code is being used incorrectly here. While 487 is the typical response to an INVITE that has been terminated by a CANCEL, AFAIK there is no restriction that 487 *only* be used when a request has been canceled. I think it is technically ok to use this response here, if the goal is to be vague about why. (Or, I guess you could pretend that a proxy on the path first passed the message on, then decided to send a CANCEL. To the UAC it would look the same.) > Yes, I don't understand why vendors don't use "403 Forbidden" (with > appropiate reason phrase) in these cases. I do agree that if the intent was to forbid incoming calls from anyone not registered to this system, then 403 would be a much more suitable choice. Thanks, Paul ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] request-uri for re-subscription
I can understand how you might dislike the unusual way that forking of subscribes is handled. It is a special case. It was done that way because there was a desire to support forking of subscribe, and also a desire not to institute a transaction state machine for subscribe (akin to the one for INVITE). So it is what it is, like it or not. After a subscribe, you are expected to recognize the half-matching dialog ids and establish new dialogs for them. Sorry, Paul Iñaki Baz Castillo wrote: > 2009/7/20 Victor Pascual Avila : >> On Mon, Jul 20, 2009 at 2:41 PM, Iñaki Baz Castillo wrote: >>> Of course, the Contact in the NOTIFY from the server are equal. >> Not really-- successful SUBSCRIBE requests will receive only one >> 200-class response; however, due to forking, the subscription may have >> been accepted by multiple nodes. > > As I explained in my other mail, those servers whose 200 didn't arrive > to the susbcriber (since the proxy absorbed them) couldn't send > in-dialog NOTIFY to the subscriber (the From-tag of those NOTIFY's > wouldn't match the existing subscription dialog in the subscriber). > > ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Handling in-dialog challenges.
Brett Tate wrote: > Race conditions exists (although not likely to occur) where the remote > party's Contact may be updated between sending requests again with update > auth headers. Depending upon loose routing usage, this can impact Route > header or request-uri (see rfc3261 section 16.12.1.2). Yeah. Between your first attempt and the 2nd, you could receive an UPDATE that changes the Contact, or possibly that sends you a new offer. To cover such a case, you would be better off to recompute a new request that applies whatever change you were attempting to the current state of the dialog. (You might find that what you want is already in effect now and no request is needed.) > The likely hood of such an update is hopefully small. Small, but possible. > If I recall correctly, some are also proposing (or "fixing" rfc3261) to allow > such an update even if you rejected the update to Contact during the race > condition (such as by sending a 491). I think we cannot allow a failing request to change the target. But a success should not be rolled back even if the containing invite transaction eventually fails. Thanks, Paul >> -Original Message- >> From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip- >> implementors-boun...@lists.cs.columbia.edu] On Behalf Of M. Ranganathan >> Sent: Monday, July 20, 2009 10:20 AM >> To: sip-implementors >> Subject: [Sip-implementors] Handling in-dialog challenges. >> >> Hello >> >> I have a question about how to re-originate a request for an in-dialog >> challenge. For example, if a re-INVITE gets challenged, when sending >> the new request with credentials, would it be correct to just clone >> the old route (from the original request) set or consult the dialog >> for a change in route set? Is it even possible for that route set to >> change? > > > ___ > 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] SIP video Hold
Rajani wrote: > In SDP body for each media line we have its media attribute values set below > the media line. Each of them have default values if its not mentioned > explicitly in the body.. > >"If an offered media stream is >listed as sendrecv (or if there is no direction attribute at the >media or session level, in which case the stream is sendrecv by >default), the corresponding stream in the answer MAY be marked as >sendonly, recvonly, sendrecv, or inactive." > > Media direction attribute "a=sendrecv" is the default value if its not > present for the particular media. > > a=: > Attributes may be defined at "session-level" or at "media-level" or both. > Session level attributes are used to advertise additional information that > applies to conference as a whole. Media level attributes are specific to the > media, i.e. advertising information about the media stream. > So, in case 1 I think when a= sendonly is present at the session level, then > it will hold the connection for both audio and video. That would imply that the session level overrode the media level. But the converse it true. The session level value just overrides the default that will be used for any media stream that doesn't have a media-level value. So the cases shown work out as follows: Case: Case 1:Case 2:Case 3: -- -- -- Session: sendonly sendonly sendrecv audio:none(sendonly) none(sendonly) none(sendrecv) video:sendonly sendrecv sendonly But I suspect this is not the question that is being asked. I think the question was intended to be: "If I push the HOLD button on the video phone, does it hold audio, video, or both?" If that is the question, then neither SIP nor SDP can answer it. This is a question of UI design. You might have separate buttons for each, or one button for both, or whatever. If you are on the receiving side of a change like this you should make no assumptions about which combinations you might see. Any are possible. And of course whether session level or media level attributes are used, in what combination, is also entirely flexible. Thanks, Paul > If we want to hold only the video stream, then probably we have to include > a=sendonly attribute only for video media lines as in case 3... > > Thanks & Regards, > Rajani > > -Original Message- > From: sip-implementors-boun...@lists.cs.columbia.edu > [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of > Lakshminarayana Jayaprakash > Sent: Friday, July 17, 2009 3:23 AM > To: sip-implementors@lists.cs.columbia.edu > Subject: [Sip-implementors] SIP video Hold > > Hi, > > Is there a convention how SIP video terminal should do call hold? > Case-1: [Hold for both audio and video streams] > c=IN IP4 a.b.c.d > a=sendonly > m=audio > ... > m=video > c=IN IP4 p.q.r.t > a=sendonly > > Case-2: [Hold for audio stream only] > c=IN IP4 a.b.c.d > a=sendonly > m=audio > ... > m=video > c=IN IP4 p.q.r.t > a=sendrecv > > Case-3: [Hold for video stream only] > c=IN IP4 a.b.c.d > a=sendrecv > m=audio > ... > m=video > c=IN IP4 p.q.r.t > a=sendonly > > > Questions: > 1.Is the hold specified for both audio and video streams or one of > them? > 2.If case-2 and case-3 are possible, should the call be considered > as hold? > > Thanks in advance. > > Regards, > JP > ___ > 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 > ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Doubt in RTP(Media port)
friend friend wrote: > Dear somesh, > In hold condition, i set the media ip address as 0 and i set the > attribute as send only. > is this enough? am not setting the port as 0. > > and could you please tell me, when shall i use Inactive and send only > > please advice me. please read draft-ietf-sipping-sip-offeranswer-10 for a long discussion on this topic. Thanks, Paul > Thanks & Regards, > vijay > > --- On Fri, 3/7/09, Shanbhag, Somesh (NSN - IN/Bangalore) > wrote: > > > From: Shanbhag, Somesh (NSN - IN/Bangalore) > Subject: RE: [Sip-implementors] Doubt in RTP(Media port) > To: "ext friend friend" , > sip-implementors@lists.cs.columbia.edu, shamik.s...@wipro.com > Date: Friday, 3 July, 2009, 7:06 PM > > > Vijay: > > There is also one more implementation widely used. If you make your port as > 0, this will also result in an Hold condition. > > There are two approaches used: > > (1) Make port as zero > (2) Include a=sendonly attribute > > > Somesh > > -Original Message- > From: sip-implementors-boun...@lists.cs.columbia.edu > [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of ext > friend friend > Sent: Friday, July 03, 2009 5:48 PM > To: sip-implementors@lists.cs.columbia.edu; shamik.s...@wipro.com > Subject: Re: [Sip-implementors] Doubt in RTP(Media port) > > Thanks for your Information > > Regards, > vijay > > --- On Fri, 3/7/09, shamik.s...@wipro.com wrote: > > > From: shamik.s...@wipro.com > Subject: Re: [Sip-implementors] Doubt in RTP(Media port) > To: sip_qu...@yahoo.co.in, sip-implementors@lists.cs.columbia.edu > Date: Friday, 3 July, 2009, 5:05 PM > > > > > During call hold just change the attribute to inactive don't change the media > port. > > > Thanks and regards, > > Shamik Saha > Project Engineer > Voice Protocols > Cell : +91-9886704155 > > -Original Message- > From: sip-implementors-boun...@lists.cs.columbia.edu > [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of > sip_qu...@yahoo.co.in > Sent: Friday, July 03, 2009 5:02 PM > To: sip fourm > Subject: [Sip-implementors] Doubt in RTP(Media port) > > > Dear Experts, > Caller sends INVITE with media port as 1000 to callee. ie caller says > to the callee, am listening in 1000. callee sends 200 OK with media port as > 2000. ie callee set the caller's ip and port(1000) and it says am listening > in 2000. after getting ACK, both ways RTP is going successfully. > > now when doing call onhold, media port shold be incremented to 1002 or same > 1000? > > please tell me the standard. > > > Thanks n Advance > > Thanks & Regards, > vijay > > > > > > > See the Web's breaking stories, chosen by people like you. Check out > Yahoo! Buzz. http://in.buzz.yahoo.com/ > ___ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > Please do not print this email unless it is absolutely necessary. > > The information contained in this electronic message and any attachments to > this message are intended for the exclusive use of the addressee(s) and may > contain proprietary, confidential or privileged information. If you are not > the intended recipient, you should not disseminate, distribute or copy this > e-mail. Please notify the sender immediately and destroy all copies of this > message and any attachments. > > WARNING: Computer viruses can be transmitted via email. The recipient should > check this email and any attachments for the presence of viruses. The company > accepts no liability for any damage caused by any virus transmitted by this > email. > > www.wipro.com > > ___ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > > Love Cricket? Check out live scores, photos, video highlights and more. > Click here http://cricket.yahoo.com > ___ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > > See the Web's breaking stories, chosen by people like you. Check > out Yahoo! Buzz. http://in.buzz.yahoo.com/ > ___ > 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] Call Transfer through a SIP trunk
Manoj Priyankara [TG] wrote: > Hi Paul, > > Sorry for using more generic terms. In this case the IP-PBX acts as a > B2BUA and the SS acts as a Proxy OK. Looking at it again, the flows you describe aren't consistent with the transfer you seem to be talking about. If C called A, and then A wants to transfer the call to B, then the goal is to have C talking to B, right? That's not what you showed. And the simple answer is that you only have two choices: - send a REFER to C, or B, to directly connect them. But I think you state the SS refuses this. (Depending on signaling, you *might* be able to bypass SS. But I doubt it.) - you must insert something, which will have to be a B2BUA, to bridge the B call leg to the C call leg. It could be A, but the PBX is a more likely candidate. But you might not have to relay the media. With some care and some luck, you might be able to offer B's sdp to C and C's to B. Then you would be in the signaling path, but not the media path. That would make it a fairly small cost. Paul > BR, > Manoj > > -Original Message- > From: sip-implementors-boun...@lists.cs.columbia.edu > [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of > Paul Kyzivat > Sent: Tuesday, June 30, 2009 6:50 PM > To: Manoj Priyankara [TG] > Cc: sip-implementors@lists.cs.columbia.edu > Subject: Re: [Sip-implementors] Call Transfer through a SIP trunk > > Manoj, > > Virtually none of the terms you use below have well defined meanings in > sip standards. Many people use such terms, but AFAIK there are not well > understood and consistent implementations for them. So it is not > possible to answer your question as posed. > > Tell us whether your SS and IP-PBX are proxies, or B2BUAs. And if > B2BUAs, do they terminate media or not. > > Then it may be possible to give you an answer. > > Thanks, > Paul > > Manoj Priyankara [TG] wrote: >> Dear all, >> >> Please consider the following scenario. >> >> Assume that there is a standard Soft Switch; and an IP PBX is > connected >> to the SS using a SIP trunk. >> >> IP PBX has a user (Say A) >> >> An incoming call comes from an external party through the SS to user > A. >> User A transfers that call to an external party. (Say B). This call > leg >> also goes through the SS >> >> >> Incoming call to A >> >> SIP Trunk >> C-> |SS|>|IP-PBX|--> A >> >> >> Transfer to B >> >> A>|IP PBX|--->|SS|---> B >> >> In this scenario, can the media be bridged from the SS and release all >> the resources in the IP PBX once the call is transferred? >> >> Thanks >> BR, >> Manoj >> >> ___ >> 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 > ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Call Transfer through a SIP trunk
Manoj, Virtually none of the terms you use below have well defined meanings in sip standards. Many people use such terms, but AFAIK there are not well understood and consistent implementations for them. So it is not possible to answer your question as posed. Tell us whether your SS and IP-PBX are proxies, or B2BUAs. And if B2BUAs, do they terminate media or not. Then it may be possible to give you an answer. Thanks, Paul Manoj Priyankara [TG] wrote: > Dear all, > > Please consider the following scenario. > > Assume that there is a standard Soft Switch; and an IP PBX is connected > to the SS using a SIP trunk. > > IP PBX has a user (Say A) > > An incoming call comes from an external party through the SS to user A. > User A transfers that call to an external party. (Say B). This call leg > also goes through the SS > > > Incoming call to A > > SIP Trunk > C-> |SS|>|IP-PBX|--> A > > > Transfer to B > > A>|IP PBX|--->|SS|---> B > > In this scenario, can the media be bridged from the SS and release all > the resources in the IP PBX once the call is transferred? > > Thanks > BR, > Manoj > > ___ > 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] SIP Redirect Server and SIP Trunks
There is a trunk-group parameter defined for the tel uri. (Can be used in sip uri when it contains a phone number.) I forget what RFC it is. Would that be what you are looking for? Paul Aniruddha Vaidya wrote: > Hello Everyone, > > I have a requirement wherein a Redirect server needs to populate > redirected address with SIP trunking information in contact header of > 302 response. > > One option that we are considering of is to use maddr parameter to > store SIP trunking information. Can you please let me if this is the > correct way to put trunking information in contact header or there is > any other mechanism of doing this? > > Thanks in Advance! > Aniruddha > ___ > 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] Information Required
Linking of registration to authorization of sessions is an IMS concept. You will need to ask this question in some IMS forum. As far as IETF is concerned, the presence, coming, or going of registrations has *no* bearing on extablished sessions, or on the ability to establish new sessions. Thanks, Paul Siddhartha Singh wrote: > Hi > I need informartion on SIP IMS behaviour in follwoing scenario: > PreCondition: > > 1. Mutiple public identities linked to one private identities are registered > in IMS. > 2. We have implicit registration enabled meaning we do not need to send > individual registration messages for all public identity. > 3.one on public identity is having active session at same time one of public > identity sends > registration message with expire header set to 0. > How should this be handled, should existing session get terminated or there > should be some error response. > Please help > > > ICC World Twenty20 England '09 exclusively on YAHOO! CRICKET > http://cricket.yahoo.com > ___ > 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] Query in Request URI
Sreenath, I'm puzzled by how you are asking this question. In general the form of the user part of a sip URI should only be of concern to the owner of the domain of that URI. So in sip:VoiceMail;userparam=12...@wcom.com, it is up to the owner of wcom.com to decide which user parts it is willing to accept. (Among those that are syntactically permitted.) So, if you are responsible for wcom.com, you may decide the above is meaningful to you, or you may reject it. Those who are *sending* requests should, in general, only be sending them to URIs that they have been given. So if somebody from wcom.com *gave* you the URI sip:VoiceMail;userparam=12...@wcom.com, then you should just send requests to it, not question whether it is valid. OTOH, if you have been given the URI sip:voicem...@wcom.com, then *in general* you have *no business* modifying it by adding a parameter to create sip:VoiceMail;userparam=12...@wcom.com. I say *in general* because that could be violated if you have some special knowledge of the policies of the wcom.com domain, that such an alteration is acceptable for URIs in its domain. Thanks, Paul Sreenath Kulkarni wrote: > Can u please provide me any reference for the same? > > Regards, > Sreenath. > > > > > > From: Iñaki Baz Castillo > To: sip-implementors@lists.cs.columbia.edu > Sent: Monday, 22 June, 2009 3:07:23 PM > Subject: Re: [Sip-implementors] Query in Request URI > > El Lunes, 22 de Junio de 2009, Sreenath Kulkarni escribió: >> Hi Sudhir, >> >> According to RFC 3261 Section 19.1.1, the sip uri should be.. >> >> sip:user:passw...@host:port;uri-parameters?headers >> >> And in Section 25 of RFC 3261 it mentioned the ABNF for SIP uri. >> >> But in the request uri its not clear that wht is the meaning of VoiceMail. >> I think the request uri should be >> INVITE sip:12...@wcome.com;userparam=VoiceMail SIP/2.0 > > Not at all. > > "VoiceMail;userparam=12345" is a 100% correct username. > > ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Query in Request URI
There is nothing wrong with that as long as wcom.com is happy with it. Regards, Paul Sudhir Kumar Reddy wrote: > Hi All, > > Can I consider following request-uri? > > INVITE sip:VoiceMail;userparam=12...@wcom.com SIP/2.0 > > any response is highly appericated > > Thanks in advance > > regards > sR > > > ICC World Twenty20 England '09 exclusively on YAHOO! CRICKET > http://cricket.yahoo.com > ___ > 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] Dial logic based on presence status
Certainly things of this sort could be useful. At least for now such things are in the realm of "products" rather than standards-based stuff. Blocking of call delivery based on presence status does require a significant degree of trust in the accuracy of the presence status. When in doubt I think it would be better to deliver the call and let the device choose to reject the call without alerting if it is in DND status. But that might not work if you have a dumb phone device and a separate device (e.g. pc) publishing presence status. That's why I think for now this is an exercise in system design. Thanks, Paul Iñaki Baz Castillo wrote: > El Miércoles, 17 de Junio de 2009, Iñaki Baz Castillo escribió: >> Hi, presence is basically defined for publishing status (user, device) and >> notify watcher about them. >> >> Would make sense if a proxy/b2bua/application_server would retrieve the >> presence status of an user in accept or reject a call for him? >> >> This is: >> >> - Bob publishes "offline" basic status. >> - Alice calls Bob. >> - The INVITE arrives to the PBX (or a proxy). >> - The PBX checks the presence status of Bob and gets "offline" (even if Bob >> is registered). >> - The PBX decides then to reject the call with "480 User Not Avilable Now". >> >> I do know that it *could* be done. My question is: does it make sense? > > Of course, other option would be the client software setting DND when the > user > selects "offline"/"away"/"busy" presence status. Some softphone do it. > > ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] XCAP: Why "org.openmobilealliance.pres-rules" instead of just "pres-rules"?
Iñaki Baz Castillo wrote: > Thanks for so great explanation. > > However, I wonder why so many new features are needed when most of the > devices > don't implement XCAP yet. The fact I don't consider useful all the new > features described above. Is it really implemented "somewhere"? I suspect the simple answer is that they don't care what you want. They are designing for 3gpp/IMS, to build a closed system that supports the features they want. I imagine they don't need or want to talk to your systems or devices. Thanks, Paul ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] SIP Endpoing Disconnection
Victor Pascual Ávila wrote: > Hi Paul, > thanks for your comments. See responses inline. > > 2009/6/11 Paul Kyzivat : >> There is really no particular value in using session timers in this case. >> Session timer is for the benefit of record-routed proxies. > > Since session timer works fine even if only one of the UAs supports it > (i.e with no proxy support), I wouldn't say that there's no particular > value in using rfc4028 here. The fact that it works doesn't imply that it has value. >> If a UA suspects that there might be a problem it can test the signaling >> path by sending an in-dialog message. It could be reINVITE, or UPDATE, or >> OPTIONS. OPTIONS isn't a great choice because there is some ambiguity about >> whether it should fail when sent "in dialog" and the dialog is gone. So >> reINVITE or UPDATE are preferred choices. >> >> This is pretty much like session timer, but need not be negotiated, and >> messages need not be sent on any schedule - just when one end or the other >> has a question about the status of the session. For instance, if media has >> stopped flowing for awhile, or ICMP messages are being received on the media >> stream, an UPDATE can be sent to check the status of the session. > > I believe it would be better to use an standard(*) mechanism > (possibility to negotiate intervals and refresher while it eliminates > the OPTIONS ambiguity) which does not assume the UAC/UAS to be > handling also the media streams (e.g. B2BUA). In addition, one could > also detect scenarios where the session has been released but the > media streams are still flowing. > > (*) SIPit23: 63% of the implementations supported rfc4028 Certainly if you want to request it in your UA, go right ahead. That may mean that even though you want to verify the session every 5 minutes you will end up doing it only every 5 hours because that is the minimum the other guy supports. Or else you will end up doing every 5 hrs for session timer and doing every 5 mins on your own, independent of session timer, to satisfy your own requirement. You can certainly do that because there is no negotiation defined to limit how frequently you may send reINVITE or UPDATE in general. There are few if any drawbacks to having each end manage session verification signaling on its own, at its own rate. If I decide I want to do every 5 hrs, then each time I receive a message from the other end I set a timer for 5 hrs. Subsequent received messages reset that timer. So as long as there is signaling I need not do any extra. If my 5 hr timer goes off, I send a reINVITE or UPDATE. If I get an acceptable answer to it I set another 5 hr timer. If not then the session is dead. The other end can be doing the same thing. If he does so more often, then I will never need to send anything to do the verification. The worst thing that can happen is glare if we both send at same time. Normally that requires backoff and retry. But if I was only sending to verify the connection then there is no need for me to retry. And same for other side. And that assumes you want periodic checks even if things are otherwise ok. Personally, in a UA with a real user, I think I will rely on the user to decide things are messed up and hang up, probably based on lack of media. If the media is flowing to the satisfaction of the user, then tearing down the call because the signaling has broken will probably not be appreciated. Thanks, Paul ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Indicating "Call Waiting" in a 1XX response
Iñaki Baz Castillo wrote: > El Jueves, 11 de Junio de 2009, Paul Kyzivat escribió: >> In one case I have a single phone with one phone number. Typically if a >> 2nd call comes in while phone is in use it is signaled to the callee in >> the media stream rather than through "ring". To switch between calls you >> typically use "flash". This is case where typically the caller might get >> a "call waiting" signal. (Because this case is considered a "call >> waiting" feature.) >> >> A 2nd case is where I have a "desk phone" with multiple "line" buttons >> on it. Those "lines" may be associated with distinct phone numbers. By >> pushing the line buttons you can connect the microphone and speaker to >> one or the other of the "lines". While a call is in place on one line, a >> call may come in on the other "line". Typically the signaling in this >> case would still be a ring, or maybe a flashing of the light on the line >> button, or both. To switch and answer the 2nd call you might have to >> first push HOLD and then press the button for the other line. In this >> case, AFAIK, the caller is *not* likely to get a "call waiting" signal. > > For the caller signalling perspective both mean the same: the callee is on a > call but has notification of this new call. > > >> The above are "traditional" renderings of a couple of different >> services. But fundamentally they are almost the same. In particular, the >> increased effort and delay to answer the 2nd call is pretty much the >> same in both cases. So if it makes sense to alert the caller to this in >> one case, it ought to make sense to do so in the other case too. > > I agree, it's exactly the same (jsut different technology but some concept). OK. We are in violent agreement. Its just "common practice" that doesn't agree! >> OTOH, I am not convinced that it makes sense in either case. Being "on >> the phone" at least means you are *near* the phone. So the time to >> answer may actually be less, on average, than when you are not on the >> phone. So what is the point in signaling anything special? > > If I call somebody (my boss) and receive "Call-Waiting in remote side" > indication, I could hang-up inmediatelly and call later (this is really > useful > in case my call is not urgent at all and I don't want to disturb my boss who > could be on an important call). You could. Of course in the meantime he might have already initiated the answer to your call, and so might be even more disturbed. :-) >> If anything, it would be better if the callee could cause a signal to be >> returned to the caller that affirmatively indicated "I acknowledge your >> call, but will need extra time before I can answer it". > > The Call-Waiting indication in the response could be generated in varios ways > by the callee: > - Automatically when an active line already exists. > - Never. > - Manually by pressing a button (notify call-waiting to caller). > > These options could be configurable in the phone. Yup! > So, if we consider 182 valid for this purpose (and I think we all agree) then > this feature would require: > - UAC implementation (display "The remote is actually on a call" upon receipt > of 182). > - UAS implemetation (with the options I mention above). > > Do yo agree? Pretty much. The 182 has a somewhat vague meaning, and it think it is fine that the meaning be that way. The implementation should be able to display whatever it wants - preferably something in line with the vague notion of 182 or it can choose to assume what it thinks is the most common usage and call it that. So it might display or say: - the remote is actually on a call - the callee is occupied but will answer you eventually - your call is waiting for the called party to answer - your call has been queued until answered - ... - any of the above in Spanish :-) Or it might just play a distinctive ringback tone. (Maybe that little tune they play on Jepardy while waiting for contestants to answer.) (Do you know Jepardy TV show where you are?) Its not really essential that all phones do the same thing, any more than it is that all phones have the same ring tone. Paul ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Indicating "Call Waiting" in a 1XX response
Iñaki Baz Castillo wrote: > El Jueves, 11 de Junio de 2009, Paul Kyzivat escribió: >> Specifically, from a caller perspective, how is a call handled via "call >> waiting" at the callee any different from the call ringing on a phone >> with two lines where the other line is in use? Why should the caller get >> a special signal in one case and not in the other case? > > Paul, i don't understand the "two" cases you mention, I just see one (as you > say): > > "the call ringing on a phone with two (or more) lines where the other >line is in use" > > Which is the second mean? In one case I have a single phone with one phone number. Typically if a 2nd call comes in while phone is in use it is signaled to the callee in the media stream rather than through "ring". To switch between calls you typically use "flash". This is case where typically the caller might get a "call waiting" signal. (Because this case is considered a "call waiting" feature.) A 2nd case is where I have a "desk phone" with multiple "line" buttons on it. Those "lines" may be associated with distinct phone numbers. By pushing the line buttons you can connect the microphone and speaker to one or the other of the "lines". While a call is in place on one line, a call may come in on the other "line". Typically the signaling in this case would still be a ring, or maybe a flashing of the light on the line button, or both. To switch and answer the 2nd call you might have to first push HOLD and then press the button for the other line. In this case, AFAIK, the caller is *not* likely to get a "call waiting" signal. The above are "traditional" renderings of a couple of different services. But fundamentally they are almost the same. In particular, the increased effort and delay to answer the 2nd call is pretty much the same in both cases. So if it makes sense to alert the caller to this in one case, it ought to make sense to do so in the other case too. OTOH, I am not convinced that it makes sense in either case. Being "on the phone" at least means you are *near* the phone. So the time to answer may actually be less, on average, than when you are not on the phone. So what is the point in signaling anything special? If anything, it would be better if the callee could cause a signal to be returned to the caller that affirmatively indicated "I acknowledge your call, but will need extra time before I can answer it". Thanks, Paul >> AFAICT, from the caller perspective this is just a "this callee may take >> an unusually long time to answer the call" indicator, and callees ought >> to be able to make their own decision about when to specify it. > > Yes, I agree :) > > ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Query for SDP Negotiation
Agree with Attila. So in the given circumstance the UAS could have responded to the invite with a 488 to indicate that it didn't support the offered media. Another possibility is for the UAS to return an answer where the port in the m-line is zero, thus rejecting the media stream since it can't handle any of the offered media. It could also include in that m-line the codecs it *does* support as an indication, though they will not be used at that time. Then the UAS could initiate another offer with the codecs it does support, in hopes of getting a working call. Whether that is better than the 488 is arguable. Probably not in most cases. Thanks, Paul Attila Sipos wrote: > 415 is often confused with 488. > > "415 Unsupported Media Type" is what you would use if if didn't understand > the SIP message body content. > > 488 (which is similar to 606) would be a more suitable response: > > 21.4.26 488 Not Acceptable Here > >The response has the same meaning as 606 (Not Acceptable), but only >applies to the specific resource addressed by the Request-URI and the >request may succeed elsewhere. > > and 606 is described as... > >The user's agent was contacted successfully but some aspects of the >session description such as the requested media, bandwidth, or >addressing style were not acceptable. > >A 606 (Not Acceptable) response means that the user wishes to >communicate, but cannot adequately support the session described. >The 606 (Not Acceptable) response MAY contain a list of reasons in a >Warning header field describing why the session described cannot be >supported. Warning reason codes are listed in Section 20.43. > > > Regards, > Attila > > > -Original Message- > From: sip-implementors-boun...@lists.cs.columbia.edu > [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Peter > Nijhuis > Sent: 27 April 2009 14:30 > To: Shanbhag, Somesh (NSN - IN/Bangalore); ext friend friend; sip fourm > Subject: Re: [Sip-implementors] Query for SDP Negotiation > > I think Callee should respond with 415 unsupported media type, since it is > not supporting media types 102, 0, 8 or 106. > > Met vriendelijke groet, with kind regards, mit freundlichen Gruß > > Peter Nijhuis > > > >> -Original Message- >> From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip- >> implementors-boun...@lists.cs.columbia.edu] On Behalf Of Shanbhag, >> Somesh (NSN - IN/Bangalore) >> Sent: maandag 27 april 2009 15:07 >> To: ext friend friend; sip fourm >> Subject: Re: [Sip-implementors] Query for SDP Negotiation >> >> The basic thing is CALLEE has to take the subset of codecs offered by >> CALLER and reply back. >> But in your case, CALLEE is replying with different set of codecs (97 >> 101) in reply to CALLER codecs ( 102 0 8 106 ) IMHO, since the >> capabilities mis-match, immdiately end the call using BYE / CANCEL >> which ever is relevant. >> >> >> Somesh >> >> -Original Message- >> From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip- >> implementors-boun...@lists.cs.columbia.edu] On Behalf Of ext friend >> friend >> Sent: Monday, April 27, 2009 2:59 PM >> To: sip fourm >> Subject: [Sip-implementors] Query for SDP Negotiation >> >> Dear Folks, >>I have doubt in the following scenario. >> >> Caller's sdp : >> >> v=0 >> o=- 1234 1 IN IP4 10.10.20.35 >> s=- >> c=IN IP4 10.10.20.35 >> t=0 0 >> m=audio 12000 RTP/AVP 102 0 8 106 >> a=rtpmap:102 iLBC/8000 >> a=rtpmap:0 PCMU/8000 >> a=rtpmap:8 PCMA/8000 >> a=rtpmap:106 telephone-event/8000 >> >> >> Callee's negotiated sdp : >> >> v=0 >> o=- 3449811996 3449811996 IN IP4 10.10.20.4 s=SJphone c=IN IP4 >> 10.10.20.4 t=0 0 m=audio 49164 RTP/AVP 97 101 c=IN IP4 10.10.20.4 >> a=rtpmap:97 iLBC/8000 >> a=rtpmap:101 telephone-event/8000 >> a=fmtp:101 0-16 >> a=setup:active >> a=sendrecv >> >> In this case,Is callee's negotiation method is wrong? >> >> Callee should send like m=audio 49164 RTP/AVP 102 106 rite? >> >> In this case, after call establishment, >> from caller sending RTP using 102 (UnKnown) >> from callee sending RTP using 97 (iLBC) >> >> So caller hearing callee's audio but callee not able to hear caller's >> audio. >> >> please clarify this issue. >> >> Thanks & Regards, >> vijay >> >> >> Bring your gang together. Do your thing. Find your favourite >> Yahoo! group at http://in.promos.yahoo.com/groups/ >> ___ >> 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 > > ___ > Sip-implementors mailing list > Sip-implementors@lists
Re: [Sip-implementors] SIP Endpoing Disconnection
There is really no particular value in using session timers in this case. Session timer is for the benefit of record-routed proxies. If a UA suspects that there might be a problem it can test the signaling path by sending an in-dialog message. It could be reINVITE, or UPDATE, or OPTIONS. OPTIONS isn't a great choice because there is some ambiguity about whether it should fail when sent "in dialog" and the dialog is gone. So reINVITE or UPDATE are preferred choices. This is pretty much like session timer, but need not be negotiated, and messages need not be sent on any schedule - just when one end or the other has a question about the status of the session. For instance, if media has stopped flowing for awhile, or ICMP messages are being received on the media stream, an UPDATE can be sent to check the status of the session. Thanks, Paul Victor Pascual Ávila wrote: > On Thu, Jun 11, 2009 at 11:11 AM, Manoj Priyankara > [TG] wrote: >> Dear All, >> >> Could one of you please explain me how to handle following situation in >> a SIP session? >> >> Let us imagine that UAC's A and B are in a call and due to a network >> connectivity problem, user A disconnects without sending any message to >> the UAS. >> Then the UAS still thinks that UAC A is alive. Of course if we have SIP >> OPTIONS kind of keep alive message then after sometime UAS can come to >> know that UAC A has not accessible and release the call. But if there is >> no such mechanism, how to handle this situation? > > Although a UA may be able to determine whether a session has timed out > by using session specific mechanisms (e.g. interpret a certain volume > of ICMP unreachable on a particular RTP destination as evidence of a > failed call), proxies are not able to do so. I'd recommend here the > use of session timers (RFC 4028). > > Cheers, ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Indicating "Call Waiting" in a 1XX response
This special treatment for "call waiting" has always baffled me. It seems to be rooted in the telco partitioning of services rather than on any fundamental difference. Specifically, from a caller perspective, how is a call handled via "call waiting" at the callee any different from the call ringing on a phone with two lines where the other line is in use? Why should the caller get a special signal in one case and not in the other case? AFAICT, from the caller perspective this is just a "this callee may take an unusually long time to answer the call" indicator, and callees ought to be able to make their own decision about when to specify it. Thanks, Paul Attila Sipos wrote: >>> 182 doesn't mean "call-waiting", it can mean "call-waiting", "queued"... > > It's the same thing isn't it? > > If you've got a "call-waiting", then your call is queued to be answered. > And you're queuing, you're a call that is waiting to be answered. > > For me, call-waiting is a type of queue (a queue of one). > > > > > > > -Original Message- > From: sip-implementors-boun...@lists.cs.columbia.edu > [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Iñaki > Baz Castillo > Sent: 10 June 2009 21:30 > To: sip-implementors@lists.cs.columbia.edu > Subject: Re: [Sip-implementors] Indicating "Call Waiting" in a 1XX response > > El Miércoles, 10 de Junio de 2009, Dale Worley escribió: > >>> Do you mean that the UAC could display the reason phrase in *English*? >>> IMHO a standarized code or "string" should be needed for this >>> instead of a custom string in English. >> Strictly speaking, the UAC would display the reason phrase in whatever >> language the reason phrase is written in. And since SIP uses Unicode >> consistently... Try >> http://www.evertype.com/standards/csur/tengwar.html >> or http://en.wikipedia.org/wiki/List_of_Unicode_characters#Dingbats > > So, if something is written with Unicode encoding... it becomes automatically > readable by anyone in the world? Great, I'll talk my grandmother about it. XD > > Ok, imagine that 180 and 183 don't exist. Instead an unique 101 code exists > and the description is the reason phrase. But any device could write that > description in whatever language (as you suggested above for 182 code) so: > > SIP/101 Ringing <-- English > SIP/101 Sonando <-- Spanish > SIP/101 Session Progress <-- English > SIP/101 Early Session<-- English too > SIP/101 En progreso <-- Spanish > > I'm sure that you don't agree with this "feature", so why do you suggest > exactly the same for 182? Note that 182 doesn't mean "call-waiting", it can > mean "call-waiting", "queued"... > > Another possibility would take place if we all agree on the real meaning of > 182: could it mean that the called has received the call but he is already on > other call? In that case 182 would just mean "call-waiting in remote side", > so our intelligent UAC doesn't require to "translate" the reason phrase and > display it to the user. > > > Thanks. > > > -- > Iñaki Baz Castillo > > ___ > 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 > ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Indicating "Call Waiting" in a 1XX response
Iñaki Baz Castillo wrote: > El Miércoles, 10 de Junio de 2009, Paul Kyzivat escribió: > >> Actually, *in theory*, you can put Accept-Language:es into your INVITE, >> and then the text messages in the response ought to be written in Spanish. >> >> (And of course everybody's SIP implementation does that. :-) > > Yes, I was to say the same XD > > > >> Practically speaking, if you want the caller to display some indication >> with a specific semantic then you do need some signaling that coveys >> that semantic. The 182, ignoring the reason phrase, comes *close* - >> close enough that IMO it would be reasonable for a UA to display some >> message that the user would reasonably interpret as call waiting. > > Ok, I like this, more than what you suggest now: > > >> To get more specific than that, I have, for quite some time, been >> promoting the concept of using Alert-Info with a URN, and defining URNs >> with specific semantics. Having one with a "call waiting" semantic would >> be quite reasonable. Alert-Info in a response is already defined, so >> this is not an abuse. The main problem preventing use of Alert-Info with >> URIs has, IMO, been one of trust - you don't know whether you are going >> to get something offensive or dangerous. Using URNs with agreed upon >> semantics eliminates that issue. > > Do you mean that the UAC receives a 1XX with Alert-Info header containing an > URN for "call waiting" so the UAC would contact the URN URI and so on? Yes. > Sincerelly I don't like this idea, why should it contact a remote server just > to understand the call-waiting concept? The point is URN, not URL. The URN is a *name*, not a *location*, so you don't contact any remote server. You either understand the name, or you don't. You are potentially able to understand it because there is a registry of URNs (in IANA) that points to a definition of what it means. But you will have to teach your software the URNs you want it to understand. So, it is really just a different extension mechanism. In this case it would be used as an extension mechanism for alerts. > Also, being realistic, most of the phones ignore Alert-Info header, or at > least, ignore contacting its URI. Am I wrong? No, you are right, I think. This is just a potential way forward for functionality of this sort, where there might be lots of different kinds of alerts that are useful, but in an environment where I don't want to fetch some URL, especially an unknown one that I might not trust. Because alerts are advisory, its probably fine if a recipient that doesn't understand one just ignores it. Alerts defined by URNs could have all sorts of different degrees of definition: - It could denote a particular tone or audio clip - It could denote a particular piece of music but not its rendition - It could be some text that is intended to be localized for the receiver - It could simply be a concept, with the rendition left open for the implementation (e.g. EMERGENCY) - ... I believe this approach is being adopted by 3gpp for some things, but I don't have the details. Of course if you just want something you can use today, this won't help. It is simply a possible direction forward. Thanks, Paul ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Indicating "Call Waiting" in a 1XX response
Iñaki Baz Castillo wrote: > El Miércoles, 10 de Junio de 2009, Dale Worley escribió: >> And a UAC might want to display the reason phrase, so you could use > > Do you mean that the UAC could display the reason phrase in *English*? IMHO a > standarized code or "string" should be needed for this instead of a custom > string in English. You mean everybody doesn't speak English? :-) Actually, *in theory*, you can put Accept-Language:es into your INVITE, and then the text messages in the response ought to be written in Spanish. (And of course everybody's SIP implementation does that. :-) Practically speaking, if you want the caller to display some indication with a specific semantic then you do need some signaling that coveys that semantic. The 182, ignoring the reason phrase, comes *close* - close enough that IMO it would be reasonable for a UA to display some message that the user would reasonably interpret as call waiting. To get more specific than that, I have, for quite some time, been promoting the concept of using Alert-Info with a URN, and defining URNs with specific semantics. Having one with a "call waiting" semantic would be quite reasonable. Alert-Info in a response is already defined, so this is not an abuse. The main problem preventing use of Alert-Info with URIs has, IMO, been one of trust - you don't know whether you are going to get something offensive or dangerous. Using URNs with agreed upon semantics eliminates that issue. Thanks, Paul >> SIP/2.0 182 Call waiting >> Another option would be a new response code: "184 Call-Waiting" but it would be very complex to make it work with existing devices which basically expect 180 and 183. >> Any UA must be prepared to receive any 1xx response and perform >> adequately. > > Sure, but do they do? :) > > Thanks. > > > ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Doubt in Instant Message
This discussion has all assumed MESSAGE. If you want to send big messages, use MSRP. Then they can be as big as you like. Multi-GB messages were considered when designing it. Paul Victor Pascual Ávila wrote: > Iñaki, > > On Fri, Jun 5, 2009 at 11:56 AM, Iñaki Baz Castillo wrote: >> 2009/6/5 Tomasz Zieleniewski : >>> Any way request size can not exceed 1300 bytes. >> Remember that TCP does exist ;) > > You cannot assume all hops along the routing path to use TCP (unless > you force it and your message possible get discarded where TCP is not > supported). > > Cheers, ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] SDP in Session Refresh Request
shamik.s...@wipro.com wrote: > Hi Paul, > > When the re-invite reaches the other end will it searches for the best > bandwith codec again from the offered codecs even if the VERSION number > is the same in the re-invite as the original invite. I don't know if it *will*, but it MAY. Thanks, Paul > Thanks and regards, > > Shamik Saha > Project Engineer > Voice Protocols > Cell : +91-9886704155 > > -----Original Message- > From: Paul Kyzivat [mailto:pkyzi...@cisco.com] > Sent: Thursday, June 04, 2009 9:05 PM > To: Attila Sipos > Cc: Shamik Saha (WT01 - Telecom Equipment); > sip-implementors@lists.cs.columbia.edu > Subject: Re: [Sip-implementors] SDP in Session Refresh Request > > > > Attila Sipos wrote: >> One more thing. >> >> I have seen UAs refresh the session using an UPDATE without any SDP. >> Doing it this way doesn't change any of the codecs. >> >> RFC 4028 says: >> It is RECOMMENDED that the UPDATE request not contain an >>offer [4], but a re-INVITE SHOULD contain one, even if the details > of >>the session have not changed. >> >> so I think this would be ok, wouldn't it? > > Yes, IMO this is the preferred approach for a simple refresh if the > parties support UPDATE. > > Thanks, > Paul > >> -Original Message- >> From: sip-implementors-boun...@lists.cs.columbia.edu >> [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of >> Paul Kyzivat >> Sent: 03 June 2009 16:42 >> To: shamik.s...@wipro.com >> Cc: sip-implementors@lists.cs.columbia.edu >> Subject: Re: [Sip-implementors] SDP in Session Refresh Request >> >> It wasn't stated who is doing the reinvite, and that can make a >> difference. >> >> Also, there is nothing special about a reinvite used for session timer > >> refresh vs any other reinvite. Only the sender of the reinvite knows >> why it was sent, and reinvites that are primarily for some other >> purpose also refresh (or cancel) the session timer. >> >> If the sender of the reinvite has no motivation for doing so other >> than refreshing the session timer, or simply verifying the state of >> the session, then it could: >> - send the same sdp it did the last time >> - send an offer reflecting how it would like the session to be >> >> What it should not do is make an offer that anticipates what it thinks > >> the other party wants, based on what it has seen as responses from the > >> other party. Doing so can get into some nasty states, not so much with > >> codecs, but with other stuff, like sendonly/recvonly. Also, you can >> never be certain that circumstances haven't changed at the other end. >> >> So, if UA1 is sending the reinvite, if it still would prefer to use >> codec B or C, then it should probably offer them again, in addition to > >> A. But it might prefer not to do that if the change would cause some >> added cost, pain, or poor user experience. For instance it it would >> require renegotiating QoS, that might be a reason not to offer a > change. >> IF, after it decides what it wants to offer, that turns out to be the >> same as what it sent last, then it should set the o-line the same as >> last time. >> >> You should also check out >> >> http://www.ietf.org/internet-drafts/draft-ietf-sipping-sip-offeranswer >> -1 >> 0.txt >> >> Thanks, >> Paul >> >> >> shamik.s...@wipro.com wrote: >>> Hi, >>> >>> I think you mean to say that the re-invite is send before the session > >>> timer expires as otherwise the session will be terminated,I think >>> this >>> re-invite should only contain codec A as it is the codec that has >>> been >>> negotiated,and the media streams for the other codec has been >>> rejected >>> by the far-end so your SDP can contain all the three codecs but only >>> codec A should be ACTIVE. >>> >>> Since the two-peer has locked down on codec A,I think this should be >>> the only active codec as the far end has not mentioned the other >>> codec's in his answer so we can be sure that there will be no change >>> of codec on the fly. >>> >>> To sum up,codec A can be the only active codec while B and C are >>> inactive. >>> >>> >>> >>> Thanks and regards, >>> >>> Shamik Saha >>> Project Engineer >>> Voice Protocols >>
Re: [Sip-implementors] SDP in Session Refresh Request
Attila Sipos wrote: > One more thing. > > I have seen UAs refresh the session using an UPDATE without any SDP. > Doing it this way doesn't change any of the codecs. > > RFC 4028 says: > It is RECOMMENDED that the UPDATE request not contain an >offer [4], but a re-INVITE SHOULD contain one, even if the details of >the session have not changed. > > so I think this would be ok, wouldn't it? Yes, IMO this is the preferred approach for a simple refresh if the parties support UPDATE. Thanks, Paul > -Original Message- > From: sip-implementors-boun...@lists.cs.columbia.edu > [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of > Paul Kyzivat > Sent: 03 June 2009 16:42 > To: shamik.s...@wipro.com > Cc: sip-implementors@lists.cs.columbia.edu > Subject: Re: [Sip-implementors] SDP in Session Refresh Request > > It wasn't stated who is doing the reinvite, and that can make a > difference. > > Also, there is nothing special about a reinvite used for session timer > refresh vs any other reinvite. Only the sender of the reinvite knows why > it was sent, and reinvites that are primarily for some other purpose > also refresh (or cancel) the session timer. > > If the sender of the reinvite has no motivation for doing so other than > refreshing the session timer, or simply verifying the state of the > session, then it could: > - send the same sdp it did the last time > - send an offer reflecting how it would like the session to be > > What it should not do is make an offer that anticipates what it thinks > the other party wants, based on what it has seen as responses from the > other party. Doing so can get into some nasty states, not so much with > codecs, but with other stuff, like sendonly/recvonly. Also, you can > never be certain that circumstances haven't changed at the other end. > > So, if UA1 is sending the reinvite, if it still would prefer to use > codec B or C, then it should probably offer them again, in addition to > A. But it might prefer not to do that if the change would cause some > added cost, pain, or poor user experience. For instance it it would > require renegotiating QoS, that might be a reason not to offer a change. > > IF, after it decides what it wants to offer, that turns out to be the > same as what it sent last, then it should set the o-line the same as > last time. > > You should also check out > > http://www.ietf.org/internet-drafts/draft-ietf-sipping-sip-offeranswer-1 > 0.txt > > Thanks, > Paul > > > shamik.s...@wipro.com wrote: >> Hi, >> >> I think you mean to say that the re-invite is send before the session >> timer expires as otherwise the session will be terminated,I think this > >> re-invite should only contain codec A as it is the codec that has been > >> negotiated,and the media streams for the other codec has been rejected > >> by the far-end so your SDP can contain all the three codecs but only >> codec A should be ACTIVE. >> >> Since the two-peer has locked down on codec A,I think this should be >> the only active codec as the far end has not mentioned the other >> codec's in his answer so we can be sure that there will be no change >> of codec on the fly. >> >> To sum up,codec A can be the only active codec while B and C are >> inactive. >> >> >> >> Thanks and regards, >> >> Shamik Saha >> Project Engineer >> Voice Protocols >> Cell : +91-9886704155 >> >> -Original Message- >> From: sip-implementors-boun...@lists.cs.columbia.edu >> [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of >> Radha krishna >> Sent: Tuesday, June 02, 2009 4:09 PM >> To: sip-implementors@lists.cs.columbia.edu >> Subject: [Sip-implementors] SDP in Session Refresh Request >> >> >> Hi All >> >> What should be the SDP in the following scenario. >> >> 1) UA1: Send INVITE with 3 codec's. A, B and C. >> 2) UA2: Received 200 with Codec A. >> 3) UA1: Session timer expired. >> 4) UA1: Sending Re-INVITE what should SDP contain? >> According to RFC we should not change SDP's, so o-line >> version MUST be same as >> initial INVITE, What about Codec? It should have A, B and >> C or just A. >> I think it should contain all three A, B and C right? >> >> Regards >> S.Radha krishna >> >> >> >> >> ___ >>
Re: [Sip-implementors] 200OK without SDP.
Good answers. Also look at http://www.ietf.org/internet-drafts/draft-ietf-sipping-sip-offeranswer-10.txt Paul Attila Sipos wrote: > yes, the call flow is fine. > > But I can understand why you are confused. > The important part is this: > For this specification, that is > only the final 2xx response to that INVITE. > > "For this specification" is important. > It allows for extensions which might permit other behaviour. > > In your case, the extension which permits other behaviour > is rfc 3262 which uses the 100rel option tag. > In RFC 3262, the behaviour allows for a reliable 18x response > to carry the SDP answer. So: > 1. If SDP is in reliable 18x, the 200 OK does not need SDP. > 2. If SDP is in reliable 18x and SDP is in the 200 OK, > then the SDP of the 200 OK should be ignored. > > Regards, > > Attila > > > > -Original Message- > From: sip-implementors-boun...@lists.cs.columbia.edu > [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of > Harsimran Singh > Sent: 01 June 2009 11:25 > To: Sip-implementors@lists.cs.columbia.edu > Subject: [Sip-implementors] 200OK without SDP. > > Hi > > I am confused about the section 13.2 of RFC 3261. The description given > in the RFC looks inconsistent. > My call flow is as follows: > > INVITE with sdp & Supp 100rel > ---> > 100 Trying > < > 180 Ringing with Req 100rel & sdp > < > PRACK no sdp > > > 200OK for prack no sdp > < > 200OK for INV no sdp <> > < > ACK > ---> > Is the above call flow correct? > > > > o If the initial offer is in an INVITE, the answer MUST be in a > reliable non-failure message from UAS back to UAC which is > correlated to that INVITE. For this specification, that is > only the final 2xx response to that INVITE. That same exact > answer MAY also be placed in any provisional responses sent > prior to the answer. The UAC MUST treat the first session > description it receives as the answer, and MUST ignore any > session descriptions in subsequent responses to the initial > INVITE. > -- > > Thanks > Harsimran Singh > ___ > 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 > ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] SRTP key transmission
A significant limitation in what you propose is that it requires Bob to have a public key that Alice knows. In general we don't find that to be the case in most telephony applications. Thanks, Paul Vadim Lebedev wrote: > I see, > Well this particular attack could be prevented by adding a timestamp + > key validity period into the encrypted material... > This is still much cheaper than using SSL in signalling path. > Actually the current approach (SSL in signalling path and rtp key in > clear in SDP) seems to be weaker in case of compromised server - the > bad guy will be able to actually HEAR,SEE and FAKE > rtp streams. > > > Anyway thanks a lot for the feedback > > Vadim > Le 2 juin 09 à 18:55, Alexander Krassiev a écrit : > >> Man in a middle. Encrypted key can be stored and re-used by man-in-a- >> middle to forge future conversations (to garble the stream). Further >> enhancing your suggestion will bring us close to SSL/TLS I am afraid. >> >> On Jun 2, 2009, at 8:27 AM, Vadim Lebedev wrote: >> >>> Vadim Lebedev wrote: >>> >>> Any thoughts on this issue? >>> I've just realised that this approach will make lawful interception >>> REALLY complicated... Maybe this >>> is the reason there is no an RFC covering it? Or am i missing >>> something? >>> >>> Thanks >>> Vadim >>> Hello, I've been reading various RFC describing tranmission of master key for SRTP unside SDP's. They require (like in rfc4568) the INVITE/200/ACK be transmitted using TLS to avoid key interception. I wonder why nobody proped following scheme: Alice generates a mester key, encrypts it wih Bob's public key and signs it with her own private key. The resulting material is stored in SDP which can be transmitted ove unsecure connection... Bob receives the INVITE request extract the signed keye authenicate the Alice signature and decodes the master key using his onw private key Thanks Vadim ___ 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 > > > ___ > 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] SDP in Session Refresh Request
It wasn't stated who is doing the reinvite, and that can make a difference. Also, there is nothing special about a reinvite used for session timer refresh vs any other reinvite. Only the sender of the reinvite knows why it was sent, and reinvites that are primarily for some other purpose also refresh (or cancel) the session timer. If the sender of the reinvite has no motivation for doing so other than refreshing the session timer, or simply verifying the state of the session, then it could: - send the same sdp it did the last time - send an offer reflecting how it would like the session to be What it should not do is make an offer that anticipates what it thinks the other party wants, based on what it has seen as responses from the other party. Doing so can get into some nasty states, not so much with codecs, but with other stuff, like sendonly/recvonly. Also, you can never be certain that circumstances haven't changed at the other end. So, if UA1 is sending the reinvite, if it still would prefer to use codec B or C, then it should probably offer them again, in addition to A. But it might prefer not to do that if the change would cause some added cost, pain, or poor user experience. For instance it it would require renegotiating QoS, that might be a reason not to offer a change. IF, after it decides what it wants to offer, that turns out to be the same as what it sent last, then it should set the o-line the same as last time. You should also check out http://www.ietf.org/internet-drafts/draft-ietf-sipping-sip-offeranswer-10.txt Thanks, Paul shamik.s...@wipro.com wrote: > Hi, > > I think you mean to say that the re-invite is send before the session > timer expires as otherwise the session will be terminated,I think this > re-invite should only contain codec A as it is the codec that has been > negotiated,and the media streams for the other codec has been rejected > by the far-end so your SDP can contain all the three codecs but only > codec A should be ACTIVE. > > Since the two-peer has locked down on codec A,I think this should be the > only active codec as the far end has not mentioned the other codec's in > his answer so we can be sure that there will be no change of codec on > the fly. > > To sum up,codec A can be the only active codec while B and C are > inactive. > > > > Thanks and regards, > > Shamik Saha > Project Engineer > Voice Protocols > Cell : +91-9886704155 > > -Original Message- > From: sip-implementors-boun...@lists.cs.columbia.edu > [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of > Radha krishna > Sent: Tuesday, June 02, 2009 4:09 PM > To: sip-implementors@lists.cs.columbia.edu > Subject: [Sip-implementors] SDP in Session Refresh Request > > > Hi All > > What should be the SDP in the following scenario. > > 1) UA1: Send INVITE with 3 codec's. A, B and C. > 2) UA2: Received 200 with Codec A. > 3) UA1: Session timer expired. > 4) UA1: Sending Re-INVITE what should SDP contain? > According to RFC we should not change SDP's, so o-line > version MUST be same as > initial INVITE, What about Codec? It should have A, B and C > or just A. > I think it should contain all three A, B and C right? > > Regards > S.Radha krishna > > > > > ___ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > Please do not print this email unless it is absolutely necessary. > > The information contained in this electronic message and any attachments to > this message are intended for the exclusive use of the addressee(s) and may > contain proprietary, confidential or privileged information. If you are not > the intended recipient, you should not disseminate, distribute or copy this > e-mail. Please notify the sender immediately and destroy all copies of this > message and any attachments. > > WARNING: Computer viruses can be transmitted via email. The recipient should > check this email and any attachments for the presence of viruses. The company > accepts no liability for any damage caused by any virus transmitted by this > email. > > www.wipro.com > > ___ > 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] subscription dialog on refer
I would just put a different spin on this without changing the facts: If you *don't* terminate the subscription with your NOTIFY, then by definition it is not the last NOTIFY, because the subscription still has to be terminated sometime, and that will entail a NOTIFY. So, if you sent a NOTIFY as part of handling the REFER, and have no expectation that you will want/need to send any additional NOTIFYs about the REFER, then you would be wise to indicate that this is the last NOTIFY, terminating the subscription. Else you need to maintain the subscription, respond to reSUBSCRIBE requests to refresh it if the come in (including sending NOTIFY with current state), and when the subscription expires you will still need to send another NOTIFY indicating termination. So you save yourself a lot of grief by just saying you are done. Paul Attila Sipos wrote: > according to RFC 3515 > > .4.7 Using the Subscription-State Header Field with Event Refer > >Each NOTIFY must contain a Subscription-State header field as defined >in [2]. The final NOTIFY sent in response to a REFER MUST indicate >the subscription has been "terminated" with a reason of "noresource". >(The resource being subscribed to is the state of the referenced >request). > > So it looks like the final NOTIFY MUST terminate the subscription. > >>> is it okay to *not* terminate this SUBSCRIBE dialog but just let >>> it timeout on some expires like a minute (handling any SUBSCRIBE >>> with Expires: with zero from transferor)? > > No. > (maybe you have some weird use case you want to elaborate on?) > > > > > -Original Message- > From: sip-implementors-boun...@lists.cs.columbia.edu > [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of > Christian Sommerfeldt > Sent: 27 May 2009 12:36 > To: sip-implementors@lists.cs.columbia.edu > Subject: [Sip-implementors] subscription dialog on refer > > When getting an in-dialog REFER we get a new SUBSCRIBE-dialog. I wonder > if it is mandatory to explisitly terminate (by means of "noresource") > this latter dialog from the transfer target once it sends the last > NOTIFY (the one with a sipfrag of 200 OK), or that it is equivaliently > alright to have the transferor terminating it with a SUBSCRIBE having > Expires: of zero. > > The question is: is it okay to *not* terminate this SUBSCRIBE dialog but > just let it timeout on some expires like a minute (handling any > SUBSCRIBE with Expires: with zero from transferor)? > ___ > 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 > ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] SIP Stacks
cool goose wrote: > Thanks All for pointing me towards some resources. I have never written any > protocol stacks before except for few small SIP tools. This would be my > first time writing a SIP stack and that's where I felt a need for some > literature or books on designing protocol stacks. Anyways, if I run into > something I will definitely let you guys now. With all due respect, unless you are a super-programmer, *and* have a year or two to work on it, you ought to be looking for an existing stack to use rather than build your own. Regards, Paul > Thank You, > CoolGoose. > > On Tue, May 19, 2009 at 12:28 PM, Brett Tate wrote: > Any of you are aware of literature on how to write SIP stacks besides the documentation provided by open source SIP stacks? >>> I mean any literature discussing the architecture and design patterns >>> used in the stack development. >> I'm sure that you can find plenty with your favorite search engine. The >> following is more of an fyi since it likely isn't the kind of detail that >> you are seeking. >> >> RFC 3261 discusses a layered approach and provides a few state machines. >> Some proposed fixes to the state machines are within >> draft-sparks-sip-invfix. RFC 5057 attempts to clarify some of dialog >> sharing issues concerning RFC 3261 and RFC 3265. >> >> The following draft humorously proposes a more radical approach to fix SIP: >> http://tools.ietf.org/id/draft-kaplan-sip-four-oh-00.txt >> >> RFC 5411 provides a snapshot of some of the SIP related RFCs and drafts. >> >> Most of the SIP design literature that I've noticed posted to >> sip-implementors (or the IETF sip lists) related to SIP design is usually >> protected by patents or licensing agreements such as the JAIN SIP JSR stuff. >> >> The following is Henning's web site in case you find anything of interest: >> http://www.cs.columbia.edu/sip/ >> >> > ___ > 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] How In early dialog state can UAC send BYE?
A plausible case is when the call is forked, and there are 180 responses from multiple forks. The UAC may then be able to determine from the answer SDP that one of the early dialogs is undesirable - lacks features it wants. So it sends a BYE to that one while allowing the other to continue ringing. For instance, this might be the case if the offer was audio/video, and one of the answers has only audio while the other has both. If video is *really* important on this call (e.g. because the caller is deaf) then this might be a reasonable behavior. Thanks, Paul kishore sowdi wrote: > Hi, > Section 15 of RFC 3261 says - "The caller’s UA MAY send a BYE for > eitherconfirmed or early dialogs, and the callee’s UA MAY send a BYE > onconfirmed dialogs, but MUST NOT send a BYE on early dialogs". > Section 12.1 of RFC 3261 says - "A dialog established by a non-final response > to a request is in the "early" state and it is called an early dialog". > Section 9.1 of RFC 3261 says - "If no provisional response has been received, > the CANCEL request MUST NOT be sent; rather, the client MUST wait for the > arrival of aprovisional response before sending the request. If the original > request has generated a final response, the CANCEL SHOULD NOT be sent, as it > is an effective no-op, since CANCEL has no effect on requests that have > already generated a final response". > So , How In early dialog state can UAC send BYE? > > I want to know the used case when caller's UA will send a BYE for a early > dailog case. > > Regards,Kishore > > > Explore and discover exciting holidays and getaways with Yahoo! India > Travel http://in.travel.yahoo.com/ > ___ > 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] can conference participate know it is in conference state with some SIP method?
A callee capability of "isfocus" on the contact header field of the far end tells you that it is a conference focus. E.g. Contact: sip:al...@atlanta.example.com;isfocus Paul wen ren wrote: > hi, all > recently I am implement some complex features about conference. usually > the conference master knows it is in > confernce state. But I want to let conference slave also konw it is in > conference state. Does any SIP method,heads, > ,event package or parameters to send this indication to slave? > thanks > ___ > 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] early media and first SIP/Kamailio Configuration
bahan...@hotmail.de wrote: > Hi, > > > I am sorry. Same Email with Subject. > > I am newcomer in SIP and Kamailio Wold an have a question. > > I have two IP Telefones and would like to realize with Kamailio What is Kamailio? > an IP Communication. The Problem: > > a. The UA 1 calls UA 2 > b. UA 2 start recording the video form UA 1, before a SIP call is established > (early media) > How can I do that? Can anybody help me or can give me Info about example > application. From a sip perspective this is simple: - The UAC includes an SDP offer in the INVITE, - the UAS may start transmitting early media toward the UAC as soon as it receives the INVITE with the offer - the UAS includes an SDP answer in the 180 response, - the UAC may start transmitting early media toward the UAS as soon as it receives the 180 with the answer Thanks, Paul ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] 487 after BYE on early dialog
Dale Worley wrote: > On Tue, 2009-05-12 at 08:47 +0200, Damir Reic wrote: >> If UAS receives BYE on early dialog and answers it with 200OK, does it have >> to respond to initial invite with 487 (same as CANCEL was received)? > > In RFC 3261 section 15.1.2, it says: > >The UAS MUST still respond to any pending requests received for that >dialog. It is RECOMMENDED that a 487 (Request Terminated) response >be generated to those pending requests. Elaborating: The uas MUST send *some* final response to the INVITE. 487 is the recommended response, but others could be used. For one thing, there could be a race, the the response could be in flight already when the BYE is received, so the UAC might get most any final response. If not, the UAC might still decide some other final response is more appropriate. For instance it might send some 5xx response. Thanks, Paul ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Question about CALL-ID in Pararell search
I agree with Dale. In addition, having the UAC do it this way makes the downstream behavior the same whether the recursion on the 300 is done by the UAC or by a proxy on the path. Thanks, Paul Dale Worley wrote: > On Mon, 2009-05-11 at 18:32 +0200, Francisco José Méndez Cirera wrote: >> A question about the CALL-ID. >> >> 1. UAC sends an INVITE request to Redirect Server with CALL-ID: abc. >> 2. Redirect server sends response "300 Multiples Choices". >> 3. UAC makes a pararell search sending three INVITES with CALL-ID: >> ¿abc?. >> >> I dont understand why first INVITE and three last INVITES have the same >> CALL-ID... > > The three INVITEs generated in step 3 are considered to be forks of the > original INVITE from step 1. > > The reason why this is the best way to organize the operation is that > the UAC only wishes to establish one dialog, with whichever of the > INVITEs receives a successful response. Since all 4 INVITEs have the > same call-id, if (through more forking downstream), one UAS receives two > INVITEs derived from them, it can responds to the second INVITE with > 482, thus avoiding having the UAS present two copies of the same logical > call to its user. > > 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] 300 Multiple Choices
Its also possible for the proxy to recurse on some of the alternatives, and then return a 300 containing some that it chose not to try itself. But an all-or-nothing approach by the proxy is much more likely. Thanks, Paul Iñaki Baz Castillo wrote: > El Miércoles, 6 de Mayo de 2009, Vito Korleone escribió: >> Hi to all SIPers, >> I think my question is simple, if A sends an INVITE to a B passing the >> INVITE of course from a proxy or BBUA.. Whatthe proxy should return to A if >> B response is 300 Multiple Choices with 2 Contacts? > > When Proxy receives a 300 from B it can do two things (depending on its local > policy/configuration): > > 1) Reply the same 300 upstream to A, so A would (if the user wants) call to > the first Contact in the 300, later to the second if first doesn't reply... > > 2) The proxy could perform "recursion", this is: the proxy takes the URI's > from the Contact received in the 300 reply and adds these URI's as new > branches so sends there the request. > > >> Should the proxy notify >> A for trying to connect him somewhere? If he don't probably atimer will >> expire? > > I didn't understand the above question. > > >> And if we have many Contacts and BBUA needs time to try them?? What >> happens then? > > What does mean "B2BUA needs time to try them"?? > > >> Oh and something else relative to 300.. When do you think the >> proxy or BBUA should try thesecond or generally next Contact in the 300?... > > It depends on "q" parameter in each Contact URI (priority). Read about "q" > parameter in RFC 3261. > > >> if the response of the a tried Contact is 4xx 5xx or 6xx? > > At this point I strongly recommend you just to read the secion about "Proxy" > in RFC 3261, it explains all your questions clearly. Don't waste time trying > to guess them. > > ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Doubt on inclussion of Contact header in 200 OK to deregistration
Iñaki Baz Castillo wrote: > 2009/5/5 Paul Kyzivat : >> Iñaki Baz Castillo wrote: >> >>> Please Bob, read the *oficially* reported bug about this subject which >>> had a long discussion some time ago: >>> http://bugs.sipit.net/show_bug.cgi?id=775 > > >> I agree with Bob that there is no bug. Its how you parse the English that >> matters. > > Paul, I think that the bug is the ambiguity in the specification. You > understand some thing, while others understand a different meaning. > IMHO there *is* a bug. > > >> IMO this is preferred to an alternative approach, which would also conform >> to the current text - include a Contact header with the Contact in the >> request, with an expires=0 parameter on it. I think I have heard of that >> being done by some implementations, and it confuses some other >> implementations, though they ought to be tolerant of it. > > An UA can send a REGISTER with no "Contact" header in order to get the > locations for its AoR. This REGISTER *doesn't* contain "Contact" > headers. > If this AoR is not registered, the how to compose the "200 OK"? The > REGISTER has no "Contact" so your suggestion above fails. We are picking over nits. The proposed change to the wording in the bug just makes it clearer that you can return a response with no contacts when there are no contacts registered. IMO the *current* wording allows returning no Contacts when there are none registered. I agree that returning a Contact with expires=0 isn't a good option if there aren't any contacts in the REGISTER request. Thanks, Paul ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Doubt on inclussion of Contact header in 200 OK to deregistration
Iñaki Baz Castillo wrote: > 2009/5/5 Bob Penfield : >> If there are no binding remaining, the 200 OK does not need to have a >> Contact header. A 200-OK response without any Contacts indicates that there >> are no bindings. > > Please Bob, read the *oficially* reported bug about this subject which > had a long discussion some time ago: > http://bugs.sipit.net/show_bug.cgi?id=775 > > Basically, what you suggest (even if it should be the correct > approach) is not what RFC 3261 states: > > --- > 10.3 Processing REGISTER Requests > > The registrar returns a 200 (OK) response. The response MUST contain > Contact header field values enumerating all current bindings. > --- I agree with Bob that there is no bug. Its how you parse the English that matters. If there are no bindings, then a response with no contacts fulfills the requirement that it "MUST contain Contact header field values enumerating all current bindings." It does indeed contain a Contact header field for each and every current binding. IMO this is preferred to an alternative approach, which would also conform to the current text - include a Contact header with the Contact in the request, with an expires=0 parameter on it. I think I have heard of that being done by some implementations, and it confuses some other implementations, though they ought to be tolerant of it. Thanks, Paul ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Multiple concurrent transactions
Stephen, I think you have arrived at the correct interpretation. In general it is *permitted*, but in most cases it is a bad idea. The cases where it might be reasonable are when the new transaction renders moot the outcome of the earlier transactions still in flight. You should *never* assume that the transactions will be properly ordered, even if you think you have a direct TCP connection between UAC and UAS. For one, that assumption breaks a lot of the flexibility of sip. For another, you (as an application) cannot assume that the transactions will be processed in order in the UAC and UAS. Because there is no guarantee of order preservation in the network, the stacks may optimize by not assuming they must preserve order either. Thanks, Paul Stephen Paterson wrote: >> No, that's not right. The UAS doesn't insist on an increment of one. >> >> It only insists that CSeq is increasing. > That's exactly what I was saying. I was giving an example of where it would > fall over if a UAS did insist on this. > > For the rest, I tend to agree but I provide a stack, not a finished UA. If my > customers want to do this, which is allowed, they should be able to. I can > recommend that they don't but not forbid it. > > Steve > >> -Original Message- >> From: Attila Sipos [mailto:attila.si...@vegastream.com] >> Sent: 05 May 2009 12:01 >> To: Stephen Paterson; Iñaki Baz Castillo >> Cc: sip-implementors@lists.cs.columbia.edu >> Subject: RE: [Sip-implementors] Multiple concurrent transactions >> >> >> and any UAS insisting on an increase of one and one only >> would reject a perfectly legitimate, in order, request. >> No, that's not right. The UAS doesn't insist on an increment of one. >> >> It only insists that CSeq is increasing. >> >> If it is allowed for multiple transactions to exist, I must >> let them if they want as it is they who build the final behaviour of >> their UA. >> >> I really don't believe the intention was to allow multiple >> transactions like this. >> >> I agree, I can't find text to say it isn't allowed but Iñaki >> has argued clearly that allowing it can cause problems. >> >> Apart from the problems described by Iñaki, there are other issues: >> 1. Debugging is more difficult >> 2. It is an inefficent use of SIP resources >>(it is effectively using the SIP transaction to queue up >> all the events) 3. it is an inefficient use of network bandwidth >>(It is flooding the network with SIP messages. >> If the network is busy or slow, it will only help >> provoke congestion) >> >> If you have events to send using INFO, you should queue them up. >> >> Regards, >> Attila >> >> >> >> >> -Original Message- >> From: sip-implementors-boun...@lists.cs.columbia.edu >> [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On >> Behalf Of Stephen Paterson >> Sent: 05 May 2009 11:43 >> To: Iñaki Baz Castillo >> Cc: sip-implementors@lists.cs.columbia.edu >> Subject: Re: [Sip-implementors] Multiple concurrent transactions >> >> OK, imagine UA1 establishes a dialog with UA2. >> UA2 then sends two INFOs which arrive out of order. UA1's >> current remote CSeq will be 0. The CSeq in the first INFO it >> receives can be anything so how would the UAS know? >> >> Also, even when only a single request is sent and the UAS >> does have a remote CSeq a proxy may still attempt to >> authenticate the request in which case the UAC would >> re-submit the request with an incremented CSeq. The UAS would >> not have seen the original request, would not know that it >> had been authenticated and any UAS insisting on an increase >> of one and one only would reject a perfectly legitimate, in >> order, request. >> >> Anyway, thanks for all your replies. From my perspective I >> just need to know what I can and can not allow my customers >> to do. If it is allowed for multiple transactions to exist, I >> must let them if they want as it is they who build the final >> behaviour of their UA. >> >> Steve >> >>> -Original Message- >>> From: sip-implementors-boun...@lists.cs.columbia.edu >>> [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On >> Behalf Of >>> Iñaki Baz Castillo >>> Sent: 05 May 2009 11:27 >>> Cc: sip-implementors@lists.cs.columbia.edu >>> Subject: Re: [Sip-implementors] Multiple concurrent transactions >>> >>> 2009/5/5 Rastogi, Vipul (Vipul) : That is correct but here we are mixing network behavior >>> with UAC behavior. UAC can send such MESSAGES, 3261 does >> not restrict >>> UAC. >>> >>> Imagine a UAC wanting to send the following DTMF sequence to a GW >>> (UAS): >>> 1 2 >>> (yes, I know that INFO is not estandarized for DTMF's... but you >>> understand me). >>> >>> Imagine that the UAC sends INFO "1" (CSeq 101) and before >> receiving a >>> reply it also sends INFO "2" (CSeq 102). >>> Due to network congestion (or whatever) the first INFO is lost. >>> INFO "2" arrives to GW (CSeq 1
Re: [Sip-implementors] What is the server side behavior if PRACK with new SDP receives (Urgent!!!!!!)
Krishna Rao Gurram wrote: > Scenario:- > UAS receives Invite with SDP. > Application above UAS sends 100 Trying > Application now sends 180 without SDP and with 100 rel. > UAS receives PRACK with SDP for 180. > Here what is the behavior of UAS? How to handle this PRACK at the UAS end. Its not a valid scenario, so the behavior is undefined. I don't see anything you could do that is highly likely to result in a successful call in this case. I guess I would be inclined to send a 200 to the PRACK, and a 400 (or pick some other error code) to the INVITE. Thanks, Paul > Please find the messages. > > INVITE sip:publi...@flextronics.com SIP/2.0 > Via: SIP/2.0/UDP 172.16.107.21:51594;branch=z9hG4bK629348334-18296 > From: Alice;tag=abc123def > To: Bob > Call-ID: 1-15...@172.16.107.21 > Cseq: 1 INVITE > Contact: sip:al...@172.16.107.21:51594 > Max-Forwards: 70 > Accept: application/sdp > Supported: 100rel, replaces > <-- > Require:100rel > Content-Type: application/sdp > Content-Length: 131 > > v=0 > o=ICF 12345 787 IN IP4 10.203.154.44 > s=Session > c=IN IP4 10.203.154.44 > t=0 0 > m=audio 4568 RTP/AVP 0 > b=AS:128 > a=ptime:20 > > > SIP/2.0 100 Trying > Via: SIP/2.0/UDP 172.16.107.21:51594;branch=z9hG4bK629348334-18296 > From: Alice;tag=abc123def > To: Bob;tag=ICF_4168957464-5666 > Call-ID: 1-15...@172.16.107.21 > -> > CSeq: 1 INVITE > Supported: timer > Contact: Bob > Content-Length: 0 > > SIP/2.0 180 Ringing > Via: SIP/2.0/UDP 172.16.107.21:51594;branch=z9hG4bK629348334-18296 > From: Alice;tag=abc123def > To: Bob;tag=ICF_4168957464-5666- - > ---> > Call-ID: 1-15...@172.16.107.21 > CSeq: 1 INVITE > Supported: 100rel,replaces,precondition,timer > Require: 100rel > RSeq: 2 > Contact: Bob > Allow: INVITE,ACK,CANCEL,BYE,OPTIONS,UPDATE > Content-Length: 0 > > > PRACK sip:publi...@flextronics.com SIP/2.0 > Via: SIP/2.0/UDP 172.16.107.21:51594;branch=z9hG4bK629348334-18296 > From: Alice;tag=abc123def > To: Bob;tag=ICF_4168957464-5666 > Call-ID: 1-15...@172.16.107.21 > Cseq: 1 PRACK > Contact: sip:al...@172.16.107.21:51594 > RAck: 2 1 INVITE > < > Max-Forwards: 70 > Accept: application/sdp > Expires: 3600 > Supported: replaces,100rel > Require:100rel > Content-type: application/sdp > Content-Length: 131 > > v=0 > o=ICF 12345 788 IN IP4 10.203.154.44 > s=Session > c=IN IP4 10.203.154.44 > t=0 0 > m=audio 4568 RTP/AVP 8 > b=AS:128 > a=ptime:20 > > "DISCLAIMER: This message is proprietary to Aricent and is intended solely > for the use of the individual to whom it is addressed. It may contain > privileged or confidential information and should not be circulated or used > for any purpose other than for what it is intended. If you have received this > message in error,please notify the originator immediately. If you are not the > intended recipient, you are notified that you are strictly prohibited from > using, copying, altering, or disclosing the contents of this message. Aricent > accepts no responsibility for loss or damage arising from the use of the > information transmitted by this email including damage from virus." > > ___ > 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] billing in sip
In a topology such as shown below, you don't need an extra media relay to enforce your billing - you have the gateway, which is already terminating the media. Why aren't you doing the billing there? Paul Iñaki Baz Castillo wrote: > 2009/4/29 Alex Balashov : >> What I meant before was that I have hacked Kamailio in the past to basically >> do this UA functionality despite it being very much a UA and not proxy thing >> to do. It originated and absorbed special re-INVITEs that were spoofed and >> basically did dlg_bye() if no response. Nasty, I know. > > Be carefull with some easy attacks like this: > > Phone1Proxy PGateway > > INVITE CSeq:1 -> ---> > <--- < 200 OK > ACK CSeq:1 > ---> > > < RTP ###> > > BYE CSeq:1 > ---> > [ ACC DONE ] > <--- <-- 400 Bad CSeq > >( audio remains ) > > > >> In the open source cottage industry world, what B2BUA do you recommend for >> high-volume applications of this? Yate perhaps? > > Not experimented too much with B2BUA in high-traffic environments :( > > > ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Query related to SUBSCRIBE Request
This isn't really the best place to discuss the logic behind IMS designs. While I have some knowledge of that, I'm not actively involved, and I find much of what is there to be strange. Good Luck Paul Dushyant Dhalia wrote: > Paul Kyzivat wrote: >> >> >> Dushyant Dhalia wrote: >>> In 3GPP specs, related to IMS procedure, it's written that P-CSCF >>> sends the SUBSCRIBE request to I-CSCF which in turns finds the >>> address of S-CSCF through Cx query. My question is why can't P-CSCF >>> send the SUBSCRIBE directly to S-CSCF using Service-Route it received >>> during Registration. >> >> A SUBSCRIBE to *what*? The Service-Route gets to the UAC's own S-CSCF. >> That's only useful if the UAC is subscribing to its own AOR. That >> might be useful for reg event subscriptions, and a few other odds and >> ends, but not in general. > Dushyant - For subscription to reg event P-CSCF is subscribing to UAC's > AoR. In any case; service-route is treated as master data for routeing > decisions of UAC i.e. for every request originated by UAC which contains > route header; P-CSCf validates the route header to see if it matches > with the service route header stored with P-CSCF. > I don't see any harm in using service route by P-CSCF, atleast for > subscription to reg event, but it will do some good i.e., it will reduce > load on I-CSCF as well as HSS. This aspect can be standardised so that > it doesn't remain a proprietary implementation. > Please comment on the above opinion. >> In any case, the use of the Service-Route is the responsibility of the >> UAC, not the P-CSCF. If the UAC has used it, then there will be a >> Route header in the request, which will influence with the P-CSCF does >> with the request. >> >> Paul > ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Query related to SUBSCRIBE Request
Dushyant Dhalia wrote: > In 3GPP specs, related to IMS procedure, it's written that P-CSCF sends > the SUBSCRIBE request to I-CSCF which in turns finds the address of > S-CSCF through Cx query. My question is why can't P-CSCF send the > SUBSCRIBE directly to S-CSCF using Service-Route it received during > Registration. A SUBSCRIBE to *what*? The Service-Route gets to the UAC's own S-CSCF. That's only useful if the UAC is subscribing to its own AOR. That might be useful for reg event subscriptions, and a few other odds and ends, but not in general. In any case, the use of the Service-Route is the responsibility of the UAC, not the P-CSCF. If the UAC has used it, then there will be a Route header in the request, which will influence with the P-CSCF does with the request. Paul ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] billing in sip
It seems that usually people who ask about billing assume that something in the signaling path can just generate billing records at start and end of call, or save some data from start of call and generate a CDR when the call ends. But that is naive. If you are only on the signaling path, not the media path, then there is much potential for clever callers to bypass the billing. Also, failures of the node that is charged with generating the billing record may not result in call termination. One question to ask is: what is the service that is being billed for? If the service is simply the session establishment service of finding the recipient of the call, then you might as well just generate a one-time, duration independent, charge. If you want to charge for the full duration of the call, then you ought to be providing some service (such as a media path) for the duration of the call. Then you can bill for as long as the path is in use. Thanks, Paul Alejandro Orellana wrote: > As mentioned here SIP does not provided in itself billing related > mechanism, > however all the information necessary is at hand. Usually the B2BUA would > gather > the critical information to formulate a Call Detailed Record that is to be > sent to an external > machine. This is normally done via some standard protocol such > RADIUS/DIAMETER. > then the RADIUS/DIAMETER server will have a backed that gets the records > and consolidate them accordingly. > > Cheers > Alejandro > > > On Mon, Apr 27, 2009 at 10:56 AM, Manish Kambdur > wrote: > >> Hi Nabam, >> >> No charging/billing messages are defined by the SIP protocol, which implies >> that the application is responsible for the billing. >> >> That is, SIP does not specify any methods for billing, and you are 'free to >> choose' and implement any application specific billing solution you need. >> >> Most often this is done in a pure SIP B2BUA as specified by Iñaki Baz >> Castillo. >> >> As an example you may consider, that the B2BUA (AS) will start a timer on >> receiving a 200 OK from callee and stops it when it gets a BYE. Now it has >> the call duration, hence you can charge based on the call duration. >> >> Regards, >> Manish >> www.huawei.com >> >> >> >> *** >> This e-mail and attachments contain confidential information from HUAWEI, >> which is intended only for the person or entity whose address is listed >> above. Any use of the information contained herein in any way (including, >> but not limited to, total or partial disclosure, reproduction, or >> dissemination) by persons other than the intended recipient's) is >> prohibited. If you receive this e-mail in error, please notify the sender >> by >> phone or email immediately and delete it! >> >> >> -Original Message- >> From: sip-implementors-boun...@lists.cs.columbia.edu >> [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of nabam >> serbang >> Sent: Monday, April 27, 2009 10:23 PM >> To: Iñaki Baz Castillo >> Cc: Sip-implementors@lists.cs.columbia.edu >> Subject: Re: [Sip-implementors] billing in sip >> >> Hi Iñaki Baz Castillo, >> >> Could you elaborate what does "SIP is not "designed" for billing" mean? I >> mean there must be some way to do billing on SIP call otherwise how service >> provider or vendor will get revenue. I understand that one way is by >> specified duration such as monthly, yearly etc. >> >> In IP-PBX based we might avoid billing but one is really required in >> IP-Centric SIP call server deployment. >> >> Regards >> ~Nabam >> >> >> >> >> >> >> >> From: Iñaki Baz Castillo >> Cc: Sip-implementors@lists.cs.columbia.edu >> Sent: Monday, April 27, 2009 6:55:58 PM >> Subject: Re: [Sip-implementors] billing in sip >> >> 2009/4/27 nabam serbang : >>> Hi, >>> Could some one tell me how billing is done is SIP? Any call flow example >> would highly be appreciated. >> >> SIP is not "designed" for billing. Also billing is too much complex >> and wide to try to explain it in an unique way. >> Basically billing can be done in a gateway (which handles also the >> media), in a proxy (very very very vulnerable), in a pure SIP B2BUA >> (more reliable and secure than a proxy for billing)... >> >> There is no magic response. >> >> >> -- >> Iñaki Baz Castillo >> >> >> ___ >> 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 >> >> >> ___ >> Sip-implementors mailing list >> Sip-implementors@lists.cs.columbia.edu >> https://lists.cs.columbia.edu/cucslists/listinfo/sip-im
Re: [Sip-implementors] redirected reinvite to be sent to which address
Scott Lawrence wrote: > On Mon, 2009-04-27 at 02:22 +0800, Avasarala Ranjit-A20990 wrote: >> Hi >> >> I do not think a SIP entity can return a 302 response with contact >> containing "mailto:"; because SIP is not a email protocol like SMTP. So I >> feel its an error to receive "mailto: in Contact as the behaviour of >> entity receiving 302 wuth mailto in contact would be that it should >> invoke a email client and expect user to compose a email !!! > > It's perfectly valid to return any type URL in a 302 - there's just no > way to be sure that whoever gets that 302 can do anything with it. Yup. There has even been some idle speculation about using this as an alternative to voicemail: - when you call me and I'm not there to answer, my phone or proxy sends a 302 with mailto: URI - when you get that, your UAC solicits a message from you, packages it as a mail attachment, and emails it to you. That works especially well if the initial invite had been for IM media, but it can work for voice and/or video too. But, as Scott notes, you have no guarantee that the caller will do this. Lacking such a guarantee, its safer to provide a server at the UAS end to collect the message. But the approach could work if accompanied by some signaling to indicate willingness of caller to do it. Thanks, Paul ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] RFC 3842: meaning of SUBSCRIBE request-uri versus To
These are interesting cases. I think they go beyond what is specified, and hence are subject to creative implementation, which in this case is probably a bad thing. I agree with the opinion that this should be treated much like an INVITE. In particular, - the request should be routed to a destination based on the R-URI. - if it doesn't reach a server responsible for the R-URI then it should fail - if it does reach a server responsible for the R-URI, then that server should first consider in that context, if there are multiple contexts in which it might be processed. Beyond that, I suppose the To uri might be treated as additional context to address what the resulting subscription might contain. In this regard I think of it again like INVITE. If I call Alice, and the call is forwarded to Bob, then the call will eventually be processed on behalf of Bob, not Alice. But Bob may still note that the call was *to* Alice, and process it differently than he might if the the call had been *to* Bob. (He might for instance say: "Hello, this is Bob, answering on behalf of Alice".) Analogously, if Bob receives a SUBSCRIBE that is To:Alice, then he might adjust what is included in the subscription on that basis. Thanks, Paul Vikram Chhibber wrote: > Yes, in all these cases, the R-URI should be considered for > identifying the target resource, but I am not sure what the "To > header" is doing in RFC 3842 as pointed out by Brett. > >If the Request-URI or To header in a message-summary subscription >corresponds to a group or collection of individual messaging >accounts, the notifier MUST specify to which account the message- >summary body corresponds. > > On Mon, Apr 20, 2009 at 3:25 PM, Iñaki Baz Castillo wrote: >> El Martes, 21 de Abril de 2009, Brett Tate escribió: >>> My specific questions are how to interpret the following upon receipt of >>> SUBSCRIBE at example.com (notifier) where user1, group1, and known-user are >>> known and unknown-user is unknown at example.com. >>> >>> 1) To: us...@example.com and request-uri is example.com? >>> >>> 2) To: example.com and request-uri is us...@example.com? >>> >>> 3) To: gro...@example.com and request-uri is us...@example.com? >>> >>> 4) To: us...@example.com and request-uri is gro...@example.com? >>> >>> 5) To: known-u...@example.com and request-uri is unknown-u...@example.com? >>> >>> 6) To: unknown-u...@example.com and request-uri is known-u...@example.com? >> This is really annoying for me and I would simplify it a lot: >> >> IMHO, even if this RFC talks about To uri (not too much in fact), the >> SUBSCRIBE must be created according to the same rules of INVITE, MESSAGE..., >> this is, the UAC creating the request must copy the RURI into the To header. >> Period. >> >> Said that, if a server receives a message-summary SUBSCRIBE with RURI being >> different from To, it could reject/drop it, or it could ignore the To uri. >> But >> the important uri is the RURI. >> >> >> -- >> Iñaki Baz Castillo >> >> ___ >> 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 > ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Query about Content-Type when Content-Length = 0
I disagree with the notion that you should include C-T:application/sdp and C-L:0 to indicate no offer. In fact, I think it is probably invalid to do so. There are at least a couple of issues with that: - If you specify a C-T, then the body needs to conform to the specification for that type. In the case of SDP, a valid SDP body always has a few lines. For instance it must have an o-line. So your zero length body will be ill-formed, resulting in an error. - If that were not the case, then the empty sdp body would be an offer. In that regard, 3261 differs from 2543. In 2543 you could have an SDP body, and if it didn't have any m-lines, then it was considered not to be an offer. In 3261, the presence of an sdp body (with C-D session) constitutes an offer (or answer) assuming it is in a place where an offer or answer is valid. This is true even if it has no m-lines. If an entirely empty sdp body were valid, then it too would be an offer if in an initial INVITE. If you want to omit the offer, then you need to omit the C-T: application/sdp as well as the body itself. Thanks, Paul Vikram Chhibber wrote: > On Mon, Apr 20, 2009 at 3:29 PM, Kevin Spencer > wrote: >> Dave, >> Thanks, thats clear from the point of view of the arbitrary binary body. >> Vikram, >> But in the case where no offer is made in the initial INVITE surely there is >> no need to indicate a content-type at that stage (it may not be known at >> that point?), for example the "Session via Redirect and Proxy Servers with >> SDP in ACK" scenario in 3665 shows the initial INVITE with a content-length >> 0 but no content-type header. > As such, there is no defined behavior in case Content-Length 0 is > defined and Content-Type is missing. > I have seen few UA which rejects initial INVITE without SDP if it has > missing type. On the safe side, you might > want to include the type even though length is 0. >> In this context would it be correct to say that while the type isn't >> necessary you should still be prepared to receive it while not necessarily >> acting upon it? > For the above context, yes, we should be lenient enough to recieve or > not receive the type if length is 0. > But we can not generalize as it very much depends on the type and context. >> Or, in the case of an SDP body does 0 length have no >> significance and the content-type shouldn't be used, and rejected if >> received - I don't see that in 4566 or 3264 though. > I do not think RFCs should be that harsh and define the behavior for > unexpected scenarios where presence > or absence of something does not violate anything. >> Thanks for the responses, >> /K >> >> On Mon, Apr 20, 2009 at 10:15 PM, Dale Worley wrote: >> >>> On Mon, 2009-04-20 at 16:21 +0100, Kevin Spencer wrote: Does anyone have any suggestions as to under what circumstances you would consider including a Content-Type: header when your Content-Length: is >>> zero? 3261 gives the following example in section 20.15: >>> I don't know of any current application, but SIP is careful to allow the >>> body to be an arbitrary (binary) object of any type. As such, we must >>> provide for the possibility that for a particular media type, a content >>> of zero bytes has a useful meaning. >>> >>> Dale >>> >> On Mon, Apr 20, 2009 at 6:4 PM, Vikram Chhibber >> wrote: >> >>> You will carry Conent-Type with 0 Content-Length when you say "I am >>> carrying 0 length XYZ Content-Type", which is different then saying "I >>> am carrying no body with an type". Typical scenario would be INVITE >>> without offer sdp. You still need to have Conent-Type as >>> "application/sdp". If you remove Content-Type itself, you can receive >>> 488 response. >>> Example of 0 Content-Length and no type would be BYE message where you >>> typically do not send any body. >> ___ >> 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 > ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] BYE after SUBSCRIBE?
shamik.s...@wipro.com wrote: > Hi Brett, > > In section 4 it is said that > > " Dialogs come into existence along with their first usage. Dialogs >terminate when their last usage is destroyed. The messages that >create and destroy usages vary per usage. This section provides a >high-level categorization of those messages. The section does not >attempt to explore the REGISTER pseudo-dialog." > > So since the invite transaction creates this dialog so this will be the > first and the founding usage of this dialogue. > > When we send the subscription request and gets back the 200OK the > subscribe usage is created which is the second usage within the initial > invite dialogue. > > > > So when we get a 481 in response to a BYE it will only terminate the > usage associated with that BYE transaction. true > Which in our case will be the subscription usage. Brett already responded to you about this. There is no single indicator in a request of which usage it belongs to. That must be determined contextually: - certain methods are tied to a particular usage: . BYE, INFO, UPDATE, (re)INVITE are always part of INVITE usage - some methods could be part of more than one usage. additional info from the message determines which one: . SUBSCRIBE, NOTIFY, PUBLISH are always part of a usage determined by the event type and id So, the BYE is part of the INVITE usage if there is one, and is in error if there is none. If we had a dialog with both INVITE and SUBSCRIBE usages, and then there can easily be cases in which both ends attempt to terminate the INVITE by sending BYE. In that case one of them will probably be getting a 481. And that should not harm the SUBSCRIBE usage. (See RFC 5407 - race-examples.) > However if the INVITE usage is destroyed after the esatblishment of the > subscription usage then the subscription usage will be the last usage > and its termination will terminate the dialog. That is true > Otherwise,the initial INVITE transaction will be unaffected. > > It is said that 481 terminate the usage > > "Destroys Usage The error destroys the usage, but not the dialog. > Any other usages sharing this dialog are not affected." > > So I think since INVITE usage is the dialog creating usage, yes > which is not > related to the BYE message it will be un-affected. no > Please let me know if my thoughts are wrong. done. Thanks, Paul > Thanks and regards, > > Shamik Saha > Project Engineer > Voice Protocols > Cell : +91-9886704155 > > -Original Message- > From: Brett Tate [mailto:br...@broadsoft.com] > Sent: Thursday, April 16, 2009 6:56 PM > To: Shamik Saha (WT01 - Telecom Equipment) > Cc: sip-implementors@lists.cs.columbia.edu > Subject: RE: [Sip-implementors] BYE after SUBSCRIBE? > > Shamik, > > Please reread section 4 concerning the distinction between INVITE usage > and SUBSCRIBE usage. > > Per tables 1 and 2, BYE 481 applies to the INVITE usage. > > -brett > >> -Original Message- >> From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip- >> implementors-boun...@lists.cs.columbia.edu] On Behalf Of >> shamik.s...@wipro.com >> Sent: Thursday, April 16, 2009 9:12 AM >> To: attila.si...@vegastream.com >> Cc: sip-implementors@lists.cs.columbia.edu >> Subject: Re: [Sip-implementors] BYE after SUBSCRIBE? >> >> But in RFC 5057 page 9,it is said that a 481 will terminate the >> SUBSCRIPTION usage but the INVITE usage dialogue within which the >> subscription is established will be un-affected. > > > Please do not print this email unless it is absolutely necessary. > > The information contained in this electronic message and any attachments to > this message are intended for the exclusive use of the addressee(s) and may > contain proprietary, confidential or privileged information. If you are not > the intended recipient, you should not disseminate, distribute or copy this > e-mail. Please notify the sender immediately and destroy all copies of this > message and any attachments. > > WARNING: Computer viruses can be transmitted via email. The recipient should > check this email and any attachments for the presence of viruses. The company > accepts no liability for any damage caused by any virus transmitted by this > email. > > www.wipro.com > > ___ > 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
