In the scenario that Bob <-> Alice Bob <-> Alice Hangs-up and B2BUA initiates a call leg to Carol for Bob..
you can do that with REFER between the subscribers without using a B2BUA and the proxy will know that this happened because he "Record Routes". Ok it's true for some other services a B2BUA is mandatory or they haven't found yet a solution using proxies and methods.. but for issues like "we are not sure if the BYE reached its destination etc" I think this should not be the problem for SIP and for that reason change the all philosophy behind it..Improve the NETWORK should be the solution! I don't know.. it's sad don't you think? Anyway thanks for the replies! Regards, Nick --- Στις Τρίτ., 24/02/09, ο/η [email protected] <[email protected]> έγραψε: > Από: [email protected] > <[email protected]> > Θέμα: Sip-implementors Digest, Vol 71, Issue 41 > Προς: [email protected] > Ημερομηνία: Τρίτη, 24 Φεβρουάριος 2009, 0:18 > Send Sip-implementors mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > or, via email, send a message with subject or body > 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more > specific > than "Re: Contents of Sip-implementors digest..." > > > Today's Topics: > > 1. Re: About hexadecimal un-escaping (Dale Worley) > 2. Re: About hexadecimal un-escaping (I?aki Baz > Castillo) > 3. Re: in-active in answer with sendonly in offer > (Andrea Rizzi) > 4. Re: CSeq header field in Register request (Dale > Worley) > 5. Re: B2BUA vs Proxy with Record Route (Dale Worley) > 6. Re: CSeq header field in Register request (cool > goose) > 7. Diagnostic idea (Dale Worley) > 8. Re: CSeq header field in Register request (Dale > Worley) > 9. Re: Diagnostic idea (Brett Tate) > 10. Re: CSeq header field in Register request (cool > goose) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 23 Feb 2009 14:20:55 -0500 > From: "Dale Worley" <[email protected]> > Subject: Re: [Sip-implementors] About hexadecimal > un-escaping > To: I?aki Baz Castillo <[email protected]> > Cc: [email protected] > Message-ID: > <[email protected]> > Content-Type: text/plain; charset=utf-8 > > On Sat, 2009-02-21 at 03:43 +0100, I?aki Baz Castillo > wrote: > > > There is no "escaping in SIP" -- there > are five or seven syntactic > > > locations in SIP URIs/name-addrs, and each has > its own escaping rules. > > > Which of those contexts are you considering? > > > > For example, URI or header paramenters keys and value > allow hexadecimal > > escaping. SIP URI username also allows hexadecimal > escaping. > > That is 5 syntactic contexts: > > user name: "unreserved" and > "user-unreserved" are allowed, uses > %-escaping > > URI parameter name: "unreserved" and > "param-unreserved" are allowed, > uses %-escaping > > URI parameter value: same as URI parameter name > > header parameter (or "header" in the BNF, *not* > field parameter) name: > "unreserved" and "hnv-unreserved" are > allowed, uses %-escaping > > As far as I know, the "+ represents space" escape > is not used in SIP > URIs in any way, only in HTTP URLs. > > Dale > > > > > > ------------------------------ > > Message: 2 > Date: Mon, 23 Feb 2009 20:34:16 +0100 > From: I?aki Baz Castillo <[email protected]> > Subject: Re: [Sip-implementors] About hexadecimal > un-escaping > To: [email protected] > Message-ID: <[email protected]> > Content-Type: text/plain; charset="utf-8" > > El Lunes, 23 de Febrero de 2009, Dale Worley escribi?: > > On Sat, 2009-02-21 at 03:43 +0100, I?aki Baz Castillo > wrote: > > > > There is no "escaping in SIP" -- > there are five or seven syntactic > > > > locations in SIP URIs/name-addrs, and each > has its own escaping rules. > > > > Which of those contexts are you considering? > > > > > > For example, URI or header paramenters keys and > value allow hexadecimal > > > escaping. SIP URI username also allows > hexadecimal escaping. > > > > That is 5 syntactic contexts: > > > > user name: "unreserved" and > "user-unreserved" are allowed, uses > > %-escaping > > > > URI parameter name: "unreserved" and > "param-unreserved" are allowed, > > uses %-escaping > > > > URI parameter value: same as URI parameter name > > > > header parameter (or "header" in the BNF, > *not* field parameter) name: > > "unreserved" and "hnv-unreserved" > are allowed, uses %-escaping > > > > As far as I know, the "+ represents space" > escape is not used in SIP > > URIs in any way, only in HTTP URLs. > > Really thanks. > > > > -- > I?aki Baz Castillo > > > > ------------------------------ > > Message: 3 > Date: Mon, 23 Feb 2009 21:18:12 +0100 > From: "Andrea Rizzi" > <[email protected]> > Subject: Re: [Sip-implementors] in-active in answer with > sendonly in > offer > To: <[email protected]> > Message-ID: > <[email protected]> > Content-Type: text/plain; charset="us-ascii" > > Answering with inactive may also be used to save bandwidth > (in addition to > DSP resources as already mentioned) in the call hold > scenario. Inactive will > force the holding party to stop sending media, leaving the > held party to > generate proper notification to the user (a message, a > special hold tone o > whatever else). In my opinion, the hold service model in > RFC 3264 is > targeted to the MOH one, while it is actually not always > really needed. > Saving bandwidth is still relevant on the access side, and > if you allow the > hold service to the user, you need to reserve a 50% more > bandwidth/line just > to play, for instance, a hold tone. Of course this would > require the CPE > (and the PSTN gateway) to play "locally" the > tone/notification, this would > be up to the operator policy (and supported by CPE/gw > vendors) > > Andrea > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 20 Feb 2009 11:42:49 -0800 (PST) > From: kaiduan xie <[email protected]> > Subject: [Sip-implementors] in-active in answer with > sendonly in offer > To: [email protected] > Message-ID: > <[email protected]> > Content-Type: text/plain; charset=iso-8859-1 > > Hi, all, > > What is the purpose of putting inactive in answer when > receiving a sendonly > offer? Rfc3264 Section 6.1 says, > > ?? "If a stream is offered as sendonly, the > corresponding stream MUST be > ?? marked as recvonly or inactive in the answer." > > In rfc5359, recvonly is returned in hold case. > > Thanks, > > kaiduan > > > > > __________________________________________________________________ > Yahoo! Canada Toolbar: Search from anywhere on the web, and > bookmark your > favourite sites. Download it now at > http://ca.toolbar.yahoo.com. > > > > > > > ------------------------------ > > Message: 4 > Date: Mon, 23 Feb 2009 16:03:04 -0500 > From: "Dale Worley" <[email protected]> > Subject: Re: [Sip-implementors] CSeq header field in > Register request > To: cool goose <[email protected]> > Cc: [email protected] > Message-ID: > <[email protected]> > Content-Type: text/plain > > On Mon, 2009-02-23 at 09:30 -0800, cool goose wrote: > > Can someone explain me the importance of CSeq in > REGISTER request? RFC 3261 > > specifies that UA must increment the CSeq value by one > for each REGISTER > > request with the same Call-ID. What is the expected > response from a > > registrar if a UA keeps retransmitting the REGISTER > request with same CSeq > > value and the same Call-ID? > > The registrar will keep a record for several minutes of the > REGISTER > that it received and the response that it gave to the > REGISTER. When it > receives a duplicate of the REGISTER, it will send a > duplicate of the > response, without further processing. (This is necessary > because the > Internet can duplicate UDP messages, and also to all the > sender to > re-send if the response gets lost.) > > After the registrar has purged memory of the REGISTER (with > that CSeq), > it will most likely respond to further REGISTERs with that > CSeq will a > 500 "Out of order" response. > > Dale > > > > > ------------------------------ > > Message: 5 > Date: Mon, 23 Feb 2009 16:07:08 -0500 > From: "Dale Worley" <[email protected]> > Subject: Re: [Sip-implementors] B2BUA vs Proxy with Record > Route > To: Vito Korleone <[email protected]> > Cc: [email protected] > Message-ID: > <[email protected]> > Content-Type: text/plain > > On Mon, 2009-02-23 at 16:52 +0000, Vito Korleone wrote: > > Why "we" need a B2BUA?? Can't we just > have the same functionality if > > we replace him with a proxy and insert the Record > Route field to trace > > all messages between the subscribers?? > > You are correct, for almost all purposes, a proxy works > very well. And > it generally has lower overhead than a B2BUA. > > For example, the sipX open-source PBX uses a proxy as the > core of its > architecture. > > Dale > > > > > ------------------------------ > > Message: 6 > Date: Mon, 23 Feb 2009 13:25:14 -0800 > From: cool goose <[email protected]> > Subject: Re: [Sip-implementors] CSeq header field in > Register request > To: Dale Worley <[email protected]> > Cc: [email protected] > Message-ID: > <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1 > > Thank You very much for the response guys! > > What about the Call-ID? If the same UA sends the REGISTER > requests with > different cal-IDs, what would be the ideal response from > the registrar? I > know that RFC 3261 prohibits from doing this. If UA fails > to use the same > Call-ID, how will it effect the registrar in ordering the > requests? > > CoolGoose. > > On Mon, Feb 23, 2009 at 1:03 PM, Dale Worley > <[email protected]> wrote: > > > On Mon, 2009-02-23 at 09:30 -0800, cool goose wrote: > > > Can someone explain me the importance of CSeq in > REGISTER request? RFC > > 3261 > > > specifies that UA must increment the CSeq value > by one for each REGISTER > > > request with the same Call-ID. What is the > expected response from a > > > registrar if a UA keeps retransmitting the > REGISTER request with same > > CSeq > > > value and the same Call-ID? > > > > The registrar will keep a record for several minutes > of the REGISTER > > that it received and the response that it gave to the > REGISTER. When it > > receives a duplicate of the REGISTER, it will send a > duplicate of the > > response, without further processing. (This is > necessary because the > > Internet can duplicate UDP messages, and also to all > the sender to > > re-send if the response gets lost.) > > > > After the registrar has purged memory of the REGISTER > (with that CSeq), > > it will most likely respond to further REGISTERs with > that CSeq will a > > 500 "Out of order" response. > > > > Dale > > > > > > > > > ------------------------------ > > Message: 7 > Date: Mon, 23 Feb 2009 16:37:27 -0500 > From: "Dale Worley" <[email protected]> > Subject: [Sip-implementors] Diagnostic idea > To: sip-implementors > <[email protected]> > Message-ID: > <[email protected]> > Content-Type: text/plain > > I've been considering the following idea for a > diagnostic tool, and I'd > like to get some feedback on it. > > The goal is to be able to trace the progress of a SIP > request through > the network, including seeing the forking structure. We > first need to > pick a provisional response codes. It appears that > "170" is not > currently used. This response code is also used as an > option-tag for > this feature. The processing is that whenever a SIP > element receives a > request that contains "Supported: 170", the > element will immediately (in > addition to anything else that it would do with the > request) send a 170 > response upstream, containing the request as its body > (media type > message/sipfrag). > > Dale > > > > > ------------------------------ > > Message: 8 > Date: Mon, 23 Feb 2009 16:41:05 -0500 > From: "Dale Worley" <[email protected]> > Subject: Re: [Sip-implementors] CSeq header field in > Register request > To: cool goose <[email protected]> > Cc: [email protected] > Message-ID: > <[email protected]> > Content-Type: text/plain > > On Mon, 2009-02-23 at 13:25 -0800, cool goose wrote: > > What about the Call-ID? If the same UA sends the > REGISTER requests > > with different cal-IDs, what would be the ideal > response from the > > registrar? I know that RFC 3261 prohibits from doing > this. If UA fails > > to use the same Call-ID, how will it effect the > registrar in ordering > > the requests? > > See RFC 3261 section 10.3. The rules are messy, but they > give the > results one would want to get. > > Dale > > > > > > ------------------------------ > > Message: 9 > Date: Mon, 23 Feb 2009 13:52:59 -0800 > From: Brett Tate <[email protected]> > Subject: Re: [Sip-implementors] Diagnostic idea > To: Dale Worley <[email protected]>, > sip-implementors > <[email protected]> > Message-ID: > <9b2a061a1137254bbe4f4b2cd843646a10b1fa9...@mbx02.citservers.local> > Content-Type: text/plain; charset="us-ascii" > > Sounds somewhat similar to > draft-ietf-sip-hop-limit-diagnostics. The 170 proposal > would potentially suffer from similar message size, > security, and privacy issues. > > > > -----Original Message----- > > From: [email protected] > [mailto:sip- > > [email protected]] On Behalf > Of Dale Worley > > Sent: Monday, February 23, 2009 4:37 PM > > To: sip-implementors > > Subject: [Sip-implementors] Diagnostic idea > > > > I've been considering the following idea for a > diagnostic tool, and I'd > > like to get some feedback on it. > > > > The goal is to be able to trace the progress of a SIP > request through > > the network, including seeing the forking structure. > We first need to > > pick a provisional response codes. It appears that > "170" is not > > currently used. This response code is also used as an > option-tag for > > this feature. The processing is that whenever a SIP > element receives a > > request that contains "Supported: 170", the > element will immediately (in > > addition to anything else that it would do with the > request) send a 170 > > response upstream, containing the request as its body > (media type > > message/sipfrag). > > > > Dale > > > > > > _______________________________________________ > > Sip-implementors mailing list > > [email protected] > > > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > > ------------------------------ > > Message: 10 > Date: Mon, 23 Feb 2009 14:18:24 -0800 > From: cool goose <[email protected]> > Subject: Re: [Sip-implementors] CSeq header field in > Register request > To: Dale Worley <[email protected]> > Cc: [email protected] > Message-ID: > <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1 > > Sec 10.3 Point #7 specifies the below: > > "If the Call-ID value in the existing binding differs > from the > Call-ID value in the request, the binding MUST be > removed if > the expiration time is zero and updated > otherwise." > > Does this mean that the Register requests from same UA can > have different > Call-IDs as long as the CSeq values are not the same? > > On Mon, Feb 23, 2009 at 1:41 PM, Dale Worley > <[email protected]> wrote: > > > On Mon, 2009-02-23 at 13:25 -0800, cool goose wrote: > > > What about the Call-ID? If the same UA sends the > REGISTER requests > > > with different cal-IDs, what would be the ideal > response from the > > > registrar? I know that RFC 3261 prohibits from > doing this. If UA fails > > > to use the same Call-ID, how will it effect the > registrar in ordering > > > the requests? > > > > See RFC 3261 section 10.3. The rules are messy, but > they give the > > results one would want to get. > > > > Dale > > > > > > > > > > > ------------------------------ > > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > End of Sip-implementors Digest, Vol 71, Issue 41 > ************************************************ ___________________________________________________________ Χρησιμοποιείτε Yahoo!; Βαρεθήκατε τα ενοχλητικά μηνύματα (spam); Το Yahoo! Mail διαθέτει την καλύτερη δυνατή προστασία κατά των ενοχλητικών μηνυμάτων http://login.yahoo.com/config/mail?.intl=gr _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
