Re: [Sip-implementors] request-uri for re-subscription
El Martes, 21 de Julio de 2009, Paul Kyzivat escribió: > I can understand how you might dislike the unusual way that forking of > subscribes is handled. It is a special case. Yes, I understand. However, IMHO it's a very bad design and most probably it will never be well implemented. As I explained in my other mail, parallel forking in subscription is really a corner case. But the logic and code to implement it in the client is really complex. I expect that a vendor cannot spend so much time to implement such an exotic and complex corner case. So again we get a feature widely NOT implemented. -- Iñaki Baz Castillo ___ 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] SIP video Hold
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. 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] 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
Re: [Sip-implementors] T.38 handling in SIP
Yeh, the mule draft is the de-facto standard I think. I believe the called party should send the re-invite because it is the called fax machine which sends a tone back to say "I'm ready to switch to fax". CED tone, I think. Regards Attila -Original Message- From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of kisteorg google Sent: 20 July 2009 16:09 To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] T.38 handling in SIP Hello list, As far as I know, usually the 1st INVITE is done by a "normal" voice codec until the calling device get a special fax signal. After that a reinvite is send from the calling device with T38 as supported codec and T38 handshaking is done. Now a vendor told me, that they "implemented the rfc" (I love that) and the called party should send an reinvite. So I was wondering about which RFC they are talking - I only know the draft-mule-sip-t38callflows-02.txt - or is there another RFC? BR Uwe ___ 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] T.38 handling in SIP
Hello list, As far as I know, usually the 1st INVITE is done by a "normal" voice codec until the calling device get a special fax signal. After that a reinvite is send from the calling device with T38 as supported codec and T38 handshaking is done. Now a vendor told me, that they "implemented the rfc" (I love that) and the called party should send an reinvite. So I was wondering about which RFC they are talking - I only know the draft-mule-sip-t38callflows-02.txt - or is there another RFC? BR Uwe ___ 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
On Mon, 2009-07-20 at 16:37 +0200, Iñaki Baz Castillo wrote: > 2009/7/20 Michael Procter : > >> No. The RURI of re-SUBSCRIBE should be the Contact received in the 200 > >> OK to the initial SUBSCRIBE, that's all. > >> Of course, the Contact in the NOTIFY from the server are equal. > > > > Not exactly. The contact in the notify will not necessarily be the > > same as the contact in the 200 response to the initial subscribe. > > Forking happens, as I like to say. A UAC whose subscribe is forked > > will only receive one 200 response (a proxy will filter the others > > out), but may receive multiple NOTIFYs, each from different endpoints. > > Sorry, but those other NOTIFY will have a different From-tag so they > will discarded with 481 by the subscriber as they don't match the > dialog (From-tag, To-tag and Call-ID) established by the subscriber > and the server whose 200 arrived to the subscriber. That would be a bug in the subscriber. A single SUBSCRIBE can create multiple dialogs if it is forked downstream, but only one of those dialogs will return a 2xx response. The first the subscriber will hear of the others is the initial NOTIFY from them; the subscriber must be prepared for this, and treat those NOTIFY requests as dialog-forming. ___ 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.
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). The likely hood of such an update is hopefully small. 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). > -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
Re: [Sip-implementors] request-uri for re-subscription
2009/7/20 Michael Procter : >> Sorry, but those other NOTIFY will have a different From-tag so they >> will discarded with 481 by the subscriber as they don't match the >> dialog (From-tag, To-tag and Call-ID) established by the subscriber >> and the server whose 200 arrived to the subscriber. > > RFC 3265 Section 3.3.4, 3rd para: > NOTIFY requests are matched to such SUBSCRIBE requests if they > contain the same "Call-ID", a "To" header "tag" parameter which > matches the "From" header "tag" parameter of the SUBSCRIBE, and the > same "Event" header field. [...] If a matching NOTIFY request > contains a "Subscription-State" of "active" or "pending", it creates > a new subscription and a new dialog (unless they have already been > created by a matching response, as described above). You are 100% right, thanks for the great clarification. However I consider this specification completely *exotic* and complex. Surely just a few implementations (if any) do it correctly. IMHO forking shouldn't exist for SUBSCRIBE. Presence is 99% handled by presence agents (presence server) so forking makes no sense. And dialog subscription (which theorically is a SUBSCRIBE arriving to the final UA) is also handled by presence agents (PBX). Since this is the real scenario usages (and they will be) IMHO it doesn't make sense so complex specification which just makes it hard to understand and implement, adding no benefict at all in the real world. -- Iñaki Baz Castillo ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] 2nd try: sip2pstn: P-Asserted-Identity and P-Preferred-Identity
Hi, >> Ok I did not receive the mail via the list. >> > > Gmail doesn't display in Inbox a mail sent by you :) > But the mail did arrive to the list: > > https://lists.cs.columbia.edu/pipermail/sip-implementors/2009-July/023186.html > > I tried to subscribe from several different emails adresses and gmail was the only which was working. >> trusted in my writing has no technical meaning. >> >> So I think the usage of the p-preferred is correct, but the setting of the >> p-asserted is wrong, since the device is not trusted to me. >> > > RFC 3325 also states that a proxy MUST ignore and remove any > P-Asserted-Identity coming from an untrusted node, so in your case you > can do it. > > However your server is doing something wrong since the 401/401 > contains a credentials with username="123452270", this is, the value > of the PAI header in the request. > Since you consider this node as untrusted, your server should ignore > and remove the PAI header(s) and take From or PPI (theorically PPI has > preference) for authentication, so the challenge in 401/407 should > contain username="12345227101". > Yes. You are right. OneAccess tries to transport ddi numbers via PAI which is far from anything I saw before. Thanks for the answer. BR Uwe ___ 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
Ahem: 2009/7/20 Iñaki Baz Castillo : > 2009/7/20 Michael Procter : >>> No. The RURI of re-SUBSCRIBE should be the Contact received in the 200 >>> OK to the initial SUBSCRIBE, that's all. >>> Of course, the Contact in the NOTIFY from the server are equal. >> >> Not exactly. The contact in the notify will not necessarily be the >> same as the contact in the 200 response to the initial subscribe. >> Forking happens, as I like to say. A UAC whose subscribe is forked >> will only receive one 200 response (a proxy will filter the others >> out), but may receive multiple NOTIFYs, each from different endpoints. > > Sorry, but those other NOTIFY will have a different From-tag so they > will discarded with 481 by the subscriber as they don't match the > dialog (From-tag, To-tag and Call-ID) established by the subscriber > and the server whose 200 arrived to the subscriber. RFC 3265 Section 3.3.4, 3rd para: NOTIFY requests are matched to such SUBSCRIBE requests if they contain the same "Call-ID", a "To" header "tag" parameter which matches the "From" header "tag" parameter of the SUBSCRIBE, and the same "Event" header field. [...] If a matching NOTIFY request contains a "Subscription-State" of "active" or "pending", it creates a new subscription and a new dialog (unless they have already been created by a matching response, as described above). >> These are likely to have different contact headers, and may have >> different route sets too. The Request URI of the reSUBSCRIBE should >> follow the normal rules for in-dialog requests, which means it will >> probably be the Contact from the NOTIFY, but might be the first entry >> in the route set if strict routing is in use. See RFC 3261 section >> 12.2.1.1 > > Impossible as I explained above. I encourage you to read the references I gave. Forking does make things more complex than the simple non-forking B2BUA scenario. Michael ___ 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.
On Mon, 2009-07-20 at 10:20 -0400, M. Ranganathan wrote: > 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? The route set is fixed by the INVITE transaction that established the dialog - it cannot be changed by any subsequent message. ___ 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.
2009/7/20 M. Ranganathan : > 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? The route set CANNOT change during a dialog. The "Route" in any in-dialog request must be, ALWAYS, the route set mirrored from the Record-Route headers in the 2XX response to the initial request. -- Iñaki Baz Castillo ___ 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
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). -- Iñaki Baz Castillo ___ 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
2009/7/20 Michael Procter : >> No. The RURI of re-SUBSCRIBE should be the Contact received in the 200 >> OK to the initial SUBSCRIBE, that's all. >> Of course, the Contact in the NOTIFY from the server are equal. > > Not exactly. The contact in the notify will not necessarily be the > same as the contact in the 200 response to the initial subscribe. > Forking happens, as I like to say. A UAC whose subscribe is forked > will only receive one 200 response (a proxy will filter the others > out), but may receive multiple NOTIFYs, each from different endpoints. Sorry, but those other NOTIFY will have a different From-tag so they will discarded with 481 by the subscriber as they don't match the dialog (From-tag, To-tag and Call-ID) established by the subscriber and the server whose 200 arrived to the subscriber. > These are likely to have different contact headers, and may have > different route sets too. The Request URI of the reSUBSCRIBE should > follow the normal rules for in-dialog requests, which means it will > probably be the Contact from the NOTIFY, but might be the first entry > in the route set if strict routing is in use. See RFC 3261 section > 12.2.1.1 Impossible as I explained above. -- Iñaki Baz Castillo ___ 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
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. Cheers, -- Victor Pascual Ávila ___ 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
Some corrections inline: 2009/7/20 Iñaki Baz Castillo : > 2009/7/20 Dushyant Dhalia : >> In NOTIFY the notifier sends its >> contact. Now my question is - is it okay for the subscriber to send >> re-subscribe with RequestURI set to the contact it received in NOTIFY? > > No. The RURI of re-SUBSCRIBE should be the Contact received in the 200 > OK to the initial SUBSCRIBE, that's all. > Of course, the Contact in the NOTIFY from the server are equal. Not exactly. The contact in the notify will not necessarily be the same as the contact in the 200 response to the initial subscribe. Forking happens, as I like to say. A UAC whose subscribe is forked will only receive one 200 response (a proxy will filter the others out), but may receive multiple NOTIFYs, each from different endpoints. These are likely to have different contact headers, and may have different route sets too. The Request URI of the reSUBSCRIBE should follow the normal rules for in-dialog requests, which means it will probably be the Contact from the NOTIFY, but might be the first entry in the route set if strict routing is in use. See RFC 3261 section 12.2.1.1 >> Secondly, regarding routeing of re-subscribe. If first SUBSCRIBE was routed >> through outbound proxy but the notifier and other nodes in the path included >> the Record-Route in Notify, is it okay for the subscriber to send >> re-subscribe through Route (by inserting route-header) it derived from >> Record-Route? > > Record-Route should be ignored in *any* in-dialog request (as NOTIFY > in a subscription dialog). Yes, but some NOTIFYs may be 'dialog-establishing', in which case the Record-Route headers should be honoured in the same way as for any other dialog-establishing method. See RFC3265 sections 3.2.3, 3.3.4, 4.4.9 and probably a few others. Regards, Michael ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
[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? Ranga -- M. Ranganathan ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] 2nd try: sip2pstn: P-Asserted-Identity and P-Preferred-Identity
2009/7/20 Uwe Kastens : >> > Looks like, that my 1st posting is lost. >> >> It's not lost, just nobody replied it. >> > > Ok I did not receive the mail via the list. Gmail doesn't display in Inbox a mail sent by you :) But the mail did arrive to the list: https://lists.cs.columbia.edu/pipermail/sip-implementors/2009-July/023186.html >> A good example for understand the difficult meaning of >> P-Preferred-Identity (and probably the only onw) is the usage with >> anonymous call, where the client sends a request containing: > > As far as I understood the rfc3325 the p-asserted is inserted for the > communication between trusted instances and should be removed if the message > is sent to an untrusted instance. Yes. > Sure. The dump is taken from the console of an OneAccess device. > > From: ;user=phone>;tag=421B > P-Asserted-Identity: > P-Preferred-Identity: > Privacy: user;id > Authorization: Digest username="123452270", >realm="sip.domain.de", >nonce="4a5c9c70742d4efb4072111d33d8ff0c495c506748f3", >uri="sip:7097...@sip.domain.de", >response="8d36e7d3f9b2237da99539a5aac34a4a", >algorithm=MD5 IMHO it doesn't make sense and it's an exotic usage of the specification. >> The point here is: what is trusted? According to exotic IETF specs, >> "trusted" requires TLS/SSL usage and so. >> But a server/proxy could consider as trusted a request from an user >> after authentication. > > trusted in my writing has no technical meaning. > > So I think the usage of the p-preferred is correct, but the setting of the > p-asserted is wrong, since the device is not trusted to me. RFC 3325 also states that a proxy MUST ignore and remove any P-Asserted-Identity coming from an untrusted node, so in your case you can do it. However your server is doing something wrong since the 401/401 contains a credentials with username="123452270", this is, the value of the PAI header in the request. Since you consider this node as untrusted, your server should ignore and remove the PAI header(s) and take From or PPI (theorically PPI has preference) for authentication, so the challenge in 401/407 should contain username="12345227101". -- Iñaki Baz Castillo ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] 2nd try: sip2pstn: P-Asserted-Identity and P-Preferred-Identity
Hello list, > > Looks like, that my 1st posting is lost. > > It's not lost, just nobody replied it. > Ok I did not receive the mail via the list. > > > A good example for understand the difficult meaning of > P-Preferred-Identity (and probably the only onw) is the usage with > anonymous call, where the client sends a request containing: As far as I understood the rfc3325 the p-asserted is inserted for the communication between trusted instances and should be removed if the message is sent to an untrusted instance. > > > I discussed with a vendor which will send me a ddi-number for a pbx as > > asserted and the main number as preferred. > > Could you paste an example of it? Sure. The dump is taken from the console of an OneAccess device. > > INVITE > call-id:oa71905eb4123452271011dd71...@sip.domain.de(UDP) > INVITE sip:7097...@sip.domain.de ;user=phone > SIP/2.0 > Accept: application/sdp,application/dtmf-relay > Allow: > > PRACK,ACK,CANCEL,BYE,SUBSCRIBE,NOTIFY,INVITE,REFER,OPTIONS,INFO,UPDATE,REGISTER > Authorization: Digest > username="123452270",realm="sip.domain.de > ",nonce="4a5c9c70742d4efb4072111d33d8ff0c495c506748f3",uri=" > sip:7097...@sip.domain.de > ",response="8d36e7d3f9b2237da99539a5aac34a4a",algorithm=MD5 > Call-ID: oa71905eb4123452271011dd71...@sip.domain.de > Contact: > Content-Type: application/sdp > CSeq: 603 INVITE > From: > ;user=phone>;tag=421B > Max-Forwards: 70 > P-Asserted-Identity: > > ;user=phone> > P-Preferred-Identity: > Privacy: user;id > Supported: replaces > To: ;user=phone> > Via: SIP/2.0/UDP 10.30.97.161:5060;branch=z9hG4bK-5C56-263 > Content-Length: 249 > > v=0 > o=sip.domain.de 3456564989 3456564989 IN IP4 10.30.97.161 > s=Session SDP > c=IN IP4 10.30.97.161 > t=0 0 > m=audio 16444 RTP/AVP 8 0 101 > a=rtpmap:8 PCMA/8000 > a=rtpmap:0 PCMU/8000 > a=rtpmap:101 telephone-event/8000 > a=fmtp:101 0-15 > a=ptime:30 > > > The RFC is not very clear in that point - or did I read the wrong ones. > > The point here is: what is trusted? According to exotic IETF specs, > "trusted" requires TLS/SSL usage and so. > But a server/proxy could consider as trusted a request from an user > after authentication. > trusted in my writing has no technical meaning. So I think the usage of the p-preferred is correct, but the setting of the p-asserted is wrong, since the device is not trusted to me. BR Uwe ___ 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
2009/7/20 Dushyant Dhalia : > I need to know what should be the request-uri for re-subscription? Is it a question? :) > The RequestURI in initial/first SUBSCRIBE is set to the resource to which > the subscriber wants to be subscribed to. Yes. > In NOTIFY the notifier sends its > contact. Now my question is - is it okay for the subscriber to send > re-subscribe with RequestURI set to the contact it received in NOTIFY? No. The RURI of re-SUBSCRIBE should be the Contact received in the 200 OK to the initial SUBSCRIBE, that's all. Of course, the Contact in the NOTIFY from the server are equal. > Secondly, regarding routeing of re-subscribe. If first SUBSCRIBE was routed > through outbound proxy but the notifier and other nodes in the path included > the Record-Route in Notify, is it okay for the subscriber to send > re-subscribe through Route (by inserting route-header) it derived from > Record-Route? Record-Route should be ignored in *any* in-dialog request (as NOTIFY in a subscription dialog). The flow is: - The client sends SUBSCRIBE. - The proxy desiring to do loose-routing add Record-Route and routes it to the presence server. - The presence server mirrors the Record-Route in the 200 OK. - Any re-SUBSCRIBE from the client or NOTIFY from the server should contain "Route" header with that value. Just it. -- 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] request-uri for re-subscription
I need to know what should be the request-uri for re-subscription? The RequestURI in initial/first SUBSCRIBE is set to the resource to which the subscriber wants to be subscribed to. In NOTIFY the notifier sends its contact. Now my question is - is it okay for the subscriber to send re-subscribe with RequestURI set to the contact it received in NOTIFY? Secondly, regarding routeing of re-subscribe. If first SUBSCRIBE was routed through outbound proxy but the notifier and other nodes in the path included the Record-Route in Notify, is it okay for the subscriber to send re-subscribe through Route (by inserting route-header) it derived from Record-Route? Dushyant P S Dhalia Rancore Technologies begin:vcard fn:Dushyant P S Dhalia n:Dhalia;Dushyant P S email;internet:dushyant.dha...@rancoretech.com version:2.1 end:vcard ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Regular expression for SIP URI
Alex Balashov wrote: > Iñaki Baz Castillo wrote: > >> 2009/7/20 Alex Balashov : You must use a SIP parser instead of a regula expression. >>> Some people try to condense the requirements of parsing a complex >>> grammar >>> into a single expression, especially when only validation is >>> required and >>> not extraction of any tokens. >> >> As I said, a regular expression for a SIP URI (strict regualr >> expression) takes ~ 50 lines so it's really slow. >> Instead, a parser is much faster and you could also use it just to >> validate the SIP URI (without extracting the fields). > > No argument. You are absolutely correct. > > I was just trying to shed light on what might compel someone to seek a > regex. Thank you guys. I was thinking, what would SipParser implementation do and hence the question. regards sankar ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Regular expression for SIP URI
Iñaki Baz Castillo wrote: > 2009/7/20 Alex Balashov : >>> You must use a SIP parser instead of a regula expression. >> Some people try to condense the requirements of parsing a complex grammar >> into a single expression, especially when only validation is required and >> not extraction of any tokens. > > As I said, a regular expression for a SIP URI (strict regualr > expression) takes ~ 50 lines so it's really slow. > Instead, a parser is much faster and you could also use it just to > validate the SIP URI (without extracting the fields). No argument. You are absolutely correct. I was just trying to shed light on what might compel someone to seek a regex. -- Alex Balashov Evariste Systems Web: http://www.evaristesys.com/ Tel: (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (678) 237-1775 ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Regular expression for SIP URI
2009/7/20 Alex Balashov : >> You must use a SIP parser instead of a regula expression. > > Some people try to condense the requirements of parsing a complex grammar > into a single expression, especially when only validation is required and > not extraction of any tokens. As I said, a regular expression for a SIP URI (strict regualr expression) takes ~ 50 lines so it's really slow. Instead, a parser is much faster and you could also use it just to validate the SIP URI (without extracting the fields). -- Iñaki Baz Castillo ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Regular expression for SIP URI
Iñaki Baz Castillo wrote: > 2009/7/20 sankara rao bhogi : >> Does any one know the regular expression for SIP URI? I know, from ABNF >> you can create regex, but I don't want to scracth my head. > > Are you looking for a regular expression to match if a string is a > correct SIP URI? > Don't do it as a SIP URI is *really complex* and the regular > expression would be *really* long (I did it some time ago and it takes > more than 50 lines). > > You must use a SIP parser instead of a regula expression. Some people try to condense the requirements of parsing a complex grammar into a single expression, especially when only validation is required and not extraction of any tokens. -- Alex Balashov Evariste Systems Web: http://www.evaristesys.com/ Tel: (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (678) 237-1775 ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Regular expression for SIP URI
2009/7/20 sankara rao bhogi : > > Does any one know the regular expression for SIP URI? I know, from ABNF > you can create regex, but I don't want to scracth my head. Are you looking for a regular expression to match if a string is a correct SIP URI? Don't do it as a SIP URI is *really complex* and the regular expression would be *really* long (I did it some time ago and it takes more than 50 lines). You must use a SIP parser instead of a regula expression. -- 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] Regular expression for SIP URI
Does any one know the regular expression for SIP URI? I know, from ABNF you can create regex, but I don't want to scracth my head. regards sankar ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] One issue in defending TCP retransmission
2009/7/20 JC : > My scenario is as follows, one SIP client sends one fresh SUBSCRIBE to > SIP server via TCP, and SIP server sends 200OK back immediately. > Unfortunately, SIP client does incorrect thing to retransmit SUBSCRIBE > once before it gets final response. > In this error case, when SIP server > sends 200OK, associated transaction releases immediately. This is correct according to RFC 3261: 17.2.2 Non-INVITE Server Transaction [...] When the server transaction enters the "Completed" state, it MUST set Timer J to fire in 64*T1 seconds for unreliable transports, and zero seconds for reliable transports. > So for > retransmitted SUBSCRIBE, transaction layer will regard it as a new msg, > not retransmitted one, and will create a new transation. And dialog > layer cann't find one matched dialog for retranmited msg because TO tag > not match, so maybe will create a new dialog. > > My question is how to defend the issue in SIP server. I think > transaction layer cann't do anything. No, it's the correct behaivour (in the server). > How about dialog layer, similar > like early notify process to change dialog matching condition? Note that, an UAC could open different dialogs against the same destination: 1) Alice can call twice to Bob (at the same time). 2) Alice can subscribe twice to Bob (at the same time). However I've a doubt here (point 2) since if Alice susbcribes twice to Bob, having both SUBSCRIBE requests the same "Contact", "From" and "RURI"... it doesn't make sense for the server to mantain two subscriptions since the server should send the *exact* NOTIFY's twice to the same "Contact". Anyhow, if the Contact of the second request is different, it should create a new subscription. This is, the server shouldn't "discard" the second SUBSCRIBE at dialog level (From tag, To tag, Call-ID). > Or let > SIP server application layer check it, e.g., the user has been > subscribed and reject it? What I would do is: - If the server receives a SUBSCRIBE with a From, RURI and Contact matching an existing subscription, the server would send 200 and the NOTIFY (as usual), but wouldn't store it in the subscription dialogs (it already exists, no need to add it again as it's useless). -- Iñaki Baz Castillo ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] 2nd try: sip2pstn: P-Asserted-Identity and P-Preferred-Identity
2009/7/20 Uwe Kastens : > Hello list, > > Looks like, that my 1st posting is lost. It's not lost, just nobody replied it. > I don't if anybody give me a hint. Until today I was very sure the the > P-Asserted-Identity is "trusted" and the P-Preferred-Identity is > "untrusted". So it is wise to map the asserted to the pstn number which > is the carrier trusted (network provided) and the preferred is a number > for clip no screening. A good example for understand the difficult meaning of P-Preferred-Identity (and probably the only onw) is the usage with anonymous call, where the client sends a request containing: INVITE sip:b...@domain2.net SIP/2.0 From: P-Preferred-Identity: Privacy: id So the proxy asks for authentication by generating a challenge with realm="domain.org" and username="alice". After authentication, the proxy removes P-Preferred-Identity and routes the request to Bob: INVITE sip:b...@domain2.net SIP/2.0 From: > I discussed with a vendor which will send me a ddi-number for a pbx as > asserted and the main number as preferred. Could you paste an example of it? > The RFC is not very clear in that point - or did I read the wrong ones. The point here is: what is trusted? According to exotic IETF specs, "trusted" requires TLS/SSL usage and so. But a server/proxy could consider as trusted a request from an user after authentication. -- Iñaki Baz Castillo ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
