[Sip-implementors] SDP in 200 to UPDATE without SDP
Hello, I am wondering what to do with an SDP in a 200 to an UPDATE without SDP in an established dialog, for example as a response to a session refresh triggered by SST. There is two cases: - the SDP has not changed (to what is established) - the SDP has changed I can't find any text neither in RFC 3311 nor in 3264 which would explicitely prohibit placing an SDP in such a 200 reply. In RFC 6337 Table 1, though, the only pattern of offer/answer involving UPDATE is the one with offer in the UPDATE, and answer in the 2xx. Or is such an SDP considered a "Session Description That Is Not an Offer or an Answer" (2.4 in 6337) and thus should just be considered informational? What if the SDP is different to the established session? Thanks for any hints! Stefan ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Retransmitted NOTIFY overlaps with the next one - what is the correct behavior?
Hello, many thanks for the explanations! o Adam Roach on 11/24/2011 06:25 AM: > > On 11/23/11 23:08, Nov 23, Paul Kyzivat wrote: >> Lets ask Adam to comment on this. >> >> Adam? > > Yeah, I saw this on the resip list but didn't have time to dig into > it. My recollection is that you're not supposed to send a NOTIFY on a > dialog while another NOTIFY is still pending on the same dialog. I > distinctly recall having discussions around this point in the > 1999-2000 timeframe, and I think we elected not to prohibit it > (although I don't remember why). It's water under the bridge at this > point. > > > ... >>> so I don't understand how in RFC 5057, section 5.1, 500 (or unknown >>> 5xx) >>> show up in "Transaction Only" and not in "Destroys Usage" - what am I >>> missing? > > RFC 5057 reflects more recent operational experience than RFC 3265. > Even though it is only informational, I would take its notion of what > destroys a dialog versus just failing a transaction to be more > informed than RFC 3265's. In fact, in the revision to RFC 3265 > currently underway, we specifically use the RFC 5057 rules for > destruction of dialogs, usages, and transactions. that's very good to hear, looking forward to that. Stefan > > So, in this case, I believe that the B2BUA stack has it wrong, and > shouldn't be terminating the dialog. This will be much clearer when > the next version of SIP Events is published. > > /a > ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Retransmitted NOTIFY overlaps with the next one - what is the correct behavior?
o Paul Kyzivat on 11/23/2011 07:17 PM:
> On 11/23/11 9:21 PM, Robert Szokovacs wrote:
>> Hi,
>>
>> I have the following setup: a B2BUA based on sipstack "A" and a mediaserver,
>> based on sipstack "B".
>> Themediaserver sends a REFER to the B2BUA which starts to send NOTIFYs
>> according to the progress of the REFERred call: for example: 100, 183,. 180,
>> 200. One of the NOTIFY gets lost on the network, lets say the 183, the "A"
>> stack retransmits it, but before the retransmittion, the 180 is sent and
>> replied:
>>
>> 100->
>> <--OK(100)
>> 183->
>> 180->
>><-OK(180)
>> 183(r)->
>><-500
>> ("A" stack terminates the subscription)
>>
>> The "B" stack refuses the retransmitted 183 NOTIFY with 500, because it's
>> cseq
>> is smaller than the 180's, which seems correct as per 12.2.2 of RFC3261:
>> "
>> If the remote sequence number was not empty, but the sequence number
>> of the request is lower than the remote sequence number, the request
>> is out of order and MUST be rejected with a 500 (Server Internal
>> Error) response.
>> "
>>
>> The "A" stack in turn terminates the subscription and the transaction dies,
>
> The main problem here is that the "A" stack should not terminate the
> subscription. This error should only affect the NOTIFY transaction at
> hand. (See RFC 5057, section 5.1).
I would have thought so, too (and IMO it's the sensible thing to
assume), but RFC 3265 3.2.2. says this:
A NOTIFY request is considered failed if the response times out, or a
non-200 class response code is received which has no "Retry-After"
header and no implied further action which can be taken to retry the
request (e.g., "401 Authorization Required".)
...
If the NOTIFY request fails (as defined above) due to an error
response, and the subscription was installed using a soft-state
mechanism, the notifier MUST remove the corresponding subscription.
A notify error response would generally indicate that something
has gone wrong with the subscriber or with some proxy on the way
to the subscriber. If the subscriber is in error, it makes the
most sense to allow the subscriber to rectify the situation (by
re-subscribing) once the error condition has been handled. If a
proxy is in error, the periodic SUBSCRIBE refreshes will re-
install subscription state once the network problem has been
resolved.
so I don't understand how in RFC 5057, section 5.1, 500 (or unknown
5xx) show up in "Transaction Only" and not in "Destroys Usage" - what
am I missing?
thanks!
Stefan
>
>> because the mediaserver application expects to receive more NOTIFYs, at least
>> one with "subscription-state: terminated", but it never comes. The "B" stack
>> doesn't notify the mediaserver application, so has no way of knowing
>> something
>> went wrong.
>>
>> What would be the correct behavior?
>> Should the B2BUA hold the sending of the next NOTIFY until it doesn't receive
>> reply to the last one?
>> Should the "A" stack marshall the NOTIFYs and make sure they don't get out of
>> order?
>
> There is a general issue with overlapping NOTIFYs if one gets lost or
> delayed, which you are seeing here. The proper way to deal with this
> depends on the details of the event package. For some event packages it
> can cause a real mess and the only good solution is to delay sending the
> next notify till the last one is known to have been received.
>
> But in other cases, like this one, it doesn't really matter much if one
> is lost as long as a subsequent one is received. So in this case its
> sufficient for "A" to send then as the state changes, so long as it
> properly handles a 500 response - by just ignoring it when a subsequent
> notify is known to have been sent.
>
>> Should the "B" stack accept out-of-order NOTIFYs?
>
> NO!
>
> Thanks,
> Paul
>
>> Thank you in advance!
>>
>> br
>>
>> Szo
>>
>>
>> ___
>> 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] RFC 2833 Telephone-Event RTP Payload Type
o Socaciu, Vlad [09/11/09 01:35]: > I found the following question raised by Mr. Greg Dykes on Sun Sep 28: > > My question really is about the actual usage of a numeric payload type > indicator. The assumption with my question is that both SIP UAs are > negotiating the same "telephone-event' RTP payload. As I understand > each SIP UA can specify their own payload type indicator (96-127) > which represents a specific, static "telephone-event" RFC 2833 RTP > payload. In other words, they don't have to make use of the same > value. So am I correct in saying that each SIP UA can indeed make use > of a different payload type indicator in the dynamic range of 96-127? > And if so does this value represent the UA's intended RTP payload type > for SENDING or RECEIVING RTP? > > Thanks, > > - Greg > > It seems to be a very clear and pertinent question. But there are no other > messages on this thread. I am facing the same dilemma. Can someone provide a > resolution? Have a look at SDP offer/answer RFC, http://www.ietf.org/rfc/rfc3264.txt, 5.1 Unicast Streams; what is said there applies to telephone-event payload as with any other dynamic payload. Here about the offerer: For recvonly RTP streams, the payload type numbers indicate the value of the payload type field in RTP packets the offerer is expecting to receive for that codec. For sendonly RTP streams, the payload type numbers indicate the value of the payload type field in RTP packets the offerer is planning to send for that codec. For sendrecv RTP streams, the payload type numbers indicate the value of the payload type field the offerer expects to receive, and would prefer to send. However, for sendonly and sendrecv streams, the answer might indicate different payload type numbers for the same codecs, in which case, the offerer MUST send with the payload type numbers from the answer. Best Regards Stefan > > Thanks. > > Vlad Socaciu > > > ___ > 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] Receiving a INVITE fro a conference server showing the current participants
o Iñaki Baz Castillo [08/31/09 15:45]: > 2009/8/31 Stefan Sayer : >> Hi Iñaki, >> >> o Iñaki Baz Castillo [08/31/09 13:23]: >>> Hi, an existing and very extended privative and diabolic VoIP protocol >>> has a cool feature about voice conference: >>> >>> 1) alice is speaking with bob. >>> 2) alice decide to invite carol to the conference. >>> 3) carol receives a call and shows the number of the participants >>> (alice and bob). >>> >>> With the current SIP conference specifications (which I have not read >>> yet): >>> >>> - Is point 2 possible? This is: creating a conference from a previous >>> user2user normal call. >> alice can set up the conference call and transfer bob and possibly carol >> into the conference. > > Yes, but this is not so useful. In most of the cases the flow is: > > - alice is speaking with bob. > - Later, both realize that carol has been connected (presente status). > - alice wants to invite carol to the *existing* conference. > > This is what people expects instead of having to call first to the > conference server, latter invite bob and carol in other phone line and > transfer them to the conference. of course this is what the phone should do (if it is 'intelligent'), not the user of the phone, who should not have to care what is happening behind the curtains. > > > >>> - Is point 3 possible? This is: the INVITE carol receives contains >>> info about the current participants and also includes some header or >> I think the idea is to SUBSCRIBE to a conference notification service that >> will give you the list of participants attending, and NOTIFY you in case of >> changes. > > Sorry but I don't understand. How could it be useful? what about > dynamically created conferences? Nobody can expect that carol is when you get the INVITE, you can fetch the status of the dynamically created conference (subscribe with expires 0), display it to your user, and if he wants to accept, subscribe again, for live status of your conference. > always subscribed to *any* conference. And anyway... does a > "subscription to conference status" exist for SIP? have a look at RFC 4353 and referenced documents. Personal opinion follows below (apologies if too much). >> A much much simpler method for a completely centralized conference: Have the >> SDP contain an u= line (see RFC4566), or the INVITE a Call-Info header (see >> 3261) with the url, and in the client display the conference status and >> control with state of the art web app GUI (not very beautiful example, but >> does have url in SDP: https://webconference.iptel.org ). REFER bob to the >> conference. > > Thanks, but what you suggest seems more a "propietary" implementation > rather than a real standard, so it would require "custom" clients > understanding these parameters in the way you suggest. Also, I expect u= line in SDP is standardized with exactly that meaning since 2327, even though apparently no one uses it in the context of SIP with SDP offer/answer. Call-Info is from RFC3261, and it doesn't seem to me that the usage is proprietary, even though unfortunately no one uses it. > that the days in which all the "cool" SIP features are implemented as > a web are close to dissapear :) and the divide between SIP networks and "innovative/cool services" is getting bigger by the day, indeed. > > The intelligence must be in the endpoints rather than in a web page :) show me a reasonably priced SIP phone that implements all of that conferencing framework (client side), supporting what you asked for above. I think this will not change in the coming years. What we are going to have much earlier is mobile and fixed devices which are much more intelligent: They are able do render complex GUIs in a full web browser, because there is demand and this is commodity technology already. For a conference that is centralized anyway (mixing, policies etc), it would IMO make sense to use the UI techniques and technologies that were developed in the web world in telco world as well, because they are simply much more advanced, interoperable, cheaper (both client and server side), flexible. Stefan ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Receiving a INVITE fro a conference server showing the current participants
Hi Iñaki, o Iñaki Baz Castillo [08/31/09 13:23]: > Hi, an existing and very extended privative and diabolic VoIP protocol > has a cool feature about voice conference: > > 1) alice is speaking with bob. > 2) alice decide to invite carol to the conference. > 3) carol receives a call and shows the number of the participants > (alice and bob). > > With the current SIP conference specifications (which I have not read yet): > > - Is point 2 possible? This is: creating a conference from a previous > user2user normal call. alice can set up the conference call and transfer bob and possibly carol into the conference. > > - Is point 3 possible? This is: the INVITE carol receives contains > info about the current participants and also includes some header or I think the idea is to SUBSCRIBE to a conference notification service that will give you the list of participants attending, and NOTIFY you in case of changes. > attribute that indicates carol that the request comes from a > conference system. grep the standards for "isfocus". A much much simpler method for a completely centralized conference: Have the SDP contain an u= line (see RFC4566), or the INVITE a Call-Info header (see 3261) with the url, and in the client display the conference status and control with state of the art web app GUI (not very beautiful example, but does have url in SDP: https://webconference.iptel.org ). REFER bob to the conference. Stefan ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] ad hoc conferences with SIP
Hello, o Dale Worley [01/20/09 21:50]: > (2) The SIP standards tend to define *mechanisms* that are utilized to > implement "features" -- E.g., a phone executes a blind transfer by > sending a REFER to the remote phone. So one UA will be the one that you can find more about transfer mechanisms in draft-ietf-sipping-cc-transfer (currently http://tools.ietf.org/html/draft-ietf-sipping-cc-transfer-11) Regards Stefan ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] In-Band DTMF
o maverick me [12/03/08 05:32]: > Hi All, > > Is there any open source available that support detection of In-Band DTMF. you could be interested in the spandsp library from http://www.soft-switch.org Stefan ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Why does 6XX break a serial forking?
o Iñaki Baz Castillo [06/03/08 14:46]:
>> It may well be that the user at that one extension noticed the caller id
>> was that nasty bill collector that he doesn't want to talk to. So he
>> pushed the "reject this call totally" button, and that resulted in the
>> 6xx response. Not sending the call to VM is exactly what was intended.
>
> Ok, but imagine my case. In calls from PSTN if the called returns 4XX/6XX I
> want to forward the request to a media server to reproduce an early
> announcement ("the number you are calling is not available now"). The called
> shouldn't have the possibility of avoiding this forwarding to the caller
> since it's a provider decission, non him decission. But 6XX breaks the
> provider if he is using a proxy and not a B2BUA.
if you really want to do that, even if your user (the callee) decided to
not take the call, it sounds to me like this is exactly a case for
B2BUA: the provider<->callee dialog is in no case to be continued. so,
if you want a caller<->provider dialog to continue in that case, you
need two dialogs, hence B2BUA.
BR,
Stefan Sayer
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] RE-INVITE Problem [packet capture inside]
[EMAIL PROTECTED] wrote: > In regard to how the answer may be different from the offer, the rules > are in section 6.1 of RFC 3264. In many cases, the answerer may add > media formats. E.g., > >For streams marked as sendrecv in the answer, the "m=" line MUST >contain at least one codec the answerer is willing to both send and >receive, from amongst those listed in the offer. The stream MAY >indicate additional media formats, not listed in the corresponding >stream in the offer, that the answerer is willing to send or >receive (of course, it will not be able to send them at this time, >since it was not listed in the offer). the payloads from the second answer are the same as the ones from the second offer (just in different order): 1st offer: Session ID: 251733463 Session Version: 1181517354 payloads: 3 98 97 8 0 101 1st answer: Session ID: 162119823 Session Version: 1294106766 payloads: 3 101 ... 2nd offer: Session ID: 251733463 Session Version: 1181517354 payloads: 3 98 97 8 0 101 2nd answer: Session ID: 162119823 Session Version: 1294106766 payloads: 98 97 8 0 3 101 > > In any case, if one is trying to debug SDP, one should have read RFC > 3264 carefully. how true. Regards Stefan Sayer -- iptego - VoIP security www.iptego.de ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] RE-INVITE Problem [packet capture inside]
Paul Kyzivat wrote: > Dale has covered this. For the original poster, Stefan: there is a lot > of written information on this subject that you don't seem to be > familiar with. The most obvious are RFCs 3261 and 3264. For a more I wonder how I made the impression to not be familiar with 3264, as I mentioned the requirement from it to increase the o-line version number if the session is to be modified (8 Modifying the Session): The offer MAY be identical to the last SDP provided to the other party (which may have been provided in an offer or an answer), or it MAY be different. We refer to the last SDP provided as the "previous SDP". If the offer is the same, the answer MAY be the same as the previous SDP from the answerer, or it MAY be different. If the offered SDP is different from the previous SDP, some constraints are placed on its construction, discussed below. [...] When issuing an offer that modifies the session, the "o=" line of the new SDP MUST be identical to that in the previous SDP, except that the version in the origin field MUST increment by one from the previous SDP. If the version in the origin line does not increment, the SDP MUST be identical to the SDP with that version number. I would say it makes sense to increase the version in the origin line as well as apply the other constraints to the modified answer too, but the text does not really say that, unlike > complete treatment, see > http://www.ietf.org/internet-drafts/draft-ietf-sipping-sip-offeranswer-02.txt where you write in 4.2.5. Subsequent Offers and Answers: o In the o-line, only the version number may change, and if it changes it must increment by one from the one previously sent as an offer or answer. If it doesn't change then the entire SDP body must be identical to what was previously sent as an offer or answer. > > Once you understand those I think your questions will be answered. > > Paul > Regards Stefan Sayer ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] RE-INVITE Problem [packet capture inside]
Hello,
[EMAIL PROTECTED] wrote:
>From: Manjunath Warad <[EMAIL PROTECTED]>
>
>I have strong doubt on the SDP that is exchanged in 200 of
>Re-INVITE. Answerer has added other media formats that he supports and I
>don't think offerer would support those and hence offerer could be
> releasing
>the call by sending ACK and BYE.
>
> Why do you have doubt? Read RFC 3264 ("An Offer/Answer Model with the
> Session Description Protocol (SDP)"), section 8 ("Modifying the
> Session"), subsection 8.3 ("Modifying a Media Stream"), subsection
> 8.3.2 ("Changing the Set of Media Formats"):
>
>The list of media formats used in the session MAY be changed. To do
>this, the offerer creates a new media description, with the list of
>media formats in the "m=" line different from the corresponding media
>stream in the previous SDP. This list MAY include new formats, and
>MAY remove formats present from the previous SDP. However, in the
>case of RTP, the mapping from a particular dynamic payload type
>number to a particular codec within that media stream MUST NOT change
>for the duration of a session.
The offerer may change the stream, but the answerer? And then, if you
change any part of the SDP, you must update (increase) the session
version, which in both SDPs of the two 200s is 1294106766.
>
> Dale
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Regards
Stefan Sayer
--
iptego - VoIP security
www.iptego.de
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
