Milo, The contact does not represent the China Airline counter. The USER represent the China Airline counter. The contacts just represent two ways of entering the China Airline offices, but once you've done that you will still reach the same user. Converting into SIP language: you are establishing a session with the USER. The contact is simply the "door" for the SIP messages to reach the SIP stack. Regards, Christer
________________________________ From: Orsic, Milo (Milo) [mailto:[EMAIL PROTECTED] Sent: 20. lokakuuta 2008 23:15 To: Christer Holmberg; SIP IETF Subject: RE: [Sip] Stupid question on flow use in outbound Hi Christer, No, you didn't follow my text below, i.e.: Choice 1. says that "the alternative flows always terminate at the single contact," or Choice 2. says that "if the alternative flows terminate on different contacts, then the contacts must have the same features." The third case (yours) is "two alternative flows terminate at different contacts, and the contacts have different features" by definition the flows are not alternatives. Why would you call it an alternative - when it gets you to a wrong place? (e.g. you used the RFC 3841 to select the proper contact - and you ended up someplace else). Cheers, Milo ------------------------------------------------------------------------ ------------------------------- -----Original Message----- From: Christer Holmberg [mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> ] Sent: Monday, October 20, 2008 2:01 PM To: Orsic, Milo (Milo); SIP IETF Subject: VS: [Sip] Stupid question on flow use in outbound Hi Milo, >IMHO outbound should specifies "alternative paths". Here is what I mean >by "alternative paths". > >Assume that China Airline has two counters (contacts), one only English >speaking the other only Chinese spiking. It doesn't matter if you took >either the escalator or the elevator to the English speaking counter >(the elevator and escalator are alternatives paths). However, if the >elevator gets you to English speaking counter and the escalator gets >you to Chinese speaking counter - they are not alternatives. >Hence, you have two choices, i.e. either 1. the two alternatives get >you to the same counter, or 2. make the second counter also English >speaking. >My choices is 1. (e.g. I don't want to be constrained that the >alternative contact addresses must be registered with the same feature >tags). So, I assume you AGREE with me: it shall be possible to register different capabilities on different flows? ...eventhough you objected when I brought it up in 3GPP ;) Regards, Christer -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> ] On Behalf Of Christer Holmberg Sent: Monday, October 20, 2008 12:56 AM To: Dean Willis; SIP IETF Subject: Re: [Sip] Stupid question on flow use in outbound Hi, >Assume Bob's UA is using outbound and is registered with two flows. >Both flows use the same instance-id. The first flow goes through edge- proxy 1 and has reg-id 1. The second flow goes through proxy 2 and has reg-id 2. > >Both flows are "live" from a keepalive perspective. > >Alice calls Bob. > >Which flow gets exercised? > >Where in Outbound is this described? If it is not in Outbound, is it described somewhere else? If it is simply left-to-the-implementation, does this need to be explained somewhere? I guess it is (for good or bad) left-to-the-implementation. HOWEVER, one thing which has been discussed, and which I think we SHOULD say something about, is whether it's allowed to use a different set of user capabilities for each flow. Personally I think it would be useful. For example, I could indicate that I want to receive incoming video calls over my super-fast-broadband access, instead of my slow jungle-drum access. I don't think we would need very much text for this either. Maybe a note saying something like: "NOTE: A user MAY register different set of user capabilities (using the mechanism in [ref-to-RFC3840] on each flow, if the user wishes the registrar to choose a particular flow based on caller preferences [ref-to-RFC3841]." ...or something like that. Regards, Christer _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip <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
