> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Juha Heinanen > Sent: 11 October 2008 22:10 > To: Dean Willis > Cc: [email protected]; Paul Kyzivat; Christer Holmberg > Subject: Re: [Sip] Dual registration without Outbound > > Dean Willis writes: > > > Seems like what you are asking for is for a proxy to > require parallel > > forking to multiple contacts regsitered by a single UA. > > huh, i'm not asking anything beyond what is in rfc3261 and what is > currently working fine in practise. or can you point to text > in rfc3261 > that prohibits a single UA registering several contacts for a single > AoR and that prohibits a proxy parallel forking to those contacts when > the contacts share the same q value? > > > That is not > > only out of scope for outbound, it is also undesirable > behaivior (as > > in totally broken) for a great number of use cases. > > i didn't know that normal rfc3261 compliant behavior is > outside of scope > of outbound. was it listed in outbound requirements that outbound > should obsolete forking that has been there from the very > beginning and > that many applications rely on? could you quote the requirements text > on that? > > also, what wrong or undesirable there is in the forking example that i > have described in earlier messages? > > > Consequently, this > > means it would require a great deal of documentation around the use > > cases for which it makes sense. I do not think this can be done > > reasonably in the outbound draft. > > outbound should not change current rfc3261 compliant forking behavior. > it has to support it and if more text is needed, then it is outbound > editors' problem. forking is much more important than outbound > especially when many UAs have already implemented things like > keepalives > without outbound. [JRE] Yes, indeed, retention of forking is very important. With RFC 3261, multiple UAs can register and incoming requests will be forked to them. With sip-outbound, this is still the case, provided these multiple UAs choose different instance IDs. This still holds true if two UAs are implemented in the same device, e.g., in your example, a dual mode device would have a GPRS UA with one instance ID and a WLAN UA with a second instance ID. If each registers, calls will be forked to both. To be sip-outbound compliant, of course, each has to register at least twice, so you will have at least two registrations (flows) with one instance ID, and at least two registrations (flows) with the second instance ID. An incoming request would be forked, such that it arrives at the device twice (and only twice), once following one of the flows for the first instance ID (GPRS) and once following one of the flows for the second instance ID (WLAN).
Perhaps we need some informative text to describe this particular use case. John > > -- juha > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use [EMAIL PROTECTED] for questions on current sip > Use [EMAIL PROTECTED] for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
