Subject: [Sip] Stupid question on flow use in outbound

From: Dean Willis <[email-masked]>
Date: Fri, 17 Oct 2008 10:04:52 -0500

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?

--
Dean
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 20 Oct 2008 07:55:43 +0200

Hi, 

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

---

From: "Orsic, Milo \(Milo\)" <[email-masked]>
Date: Mon, 20 Oct 2008 09:37:26 -0500

Hi Christer,
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). 

Milo

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 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, 

Regards,

Christer

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol Use
[email-masked] for questions on current sip Use
[email-masked] 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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 20 Oct 2008 21:00:31 +0200

Hi Milo,

>alternative contact addresses must be registered with the same feature

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-----

Hi, 

Regards,

Christer

---

From: <[email-masked]>
Date: Mon, 20 Oct 2008 22:53:36 +0300

Christer,

In what you describe below, you are assuming that in order to use your
super-fast-broadband access for video, you would also have to do your
related SIP transactions over the same interface. In general this is not
true, as you could as well run SIP over your jungle-drum interface while
putting the broadband interface addresses in your SDP. 

But I suppose we are talking about networks where some B2BUAs will get
confused if you try the media from a different IP address from where you
do SIP (although if you have something like a carrier grade NAT between
the UA and the B2BUA there is no guarantee that SIP and RTP would come
from the same IP). Perhaps it would be good enough to use two different
instance id's?
 
Markus

>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of ext Christer Holmberg
>Sent: 20 October, 2008 08:56
>proxy 1 and has reg-id 1. The second flow goes through proxy 2 
>and has reg-id 2.
>>
>described somewhere else? If it is simply 
>left-to-the-implementation, does this need to be explained somewhere?
>
>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]."
>
>[email-masked] for questions on current sip

---

From: "Orsic, Milo \(Milo\)" <[email-masked]>
Date: Mon, 20 Oct 2008 15:14:37 -0500

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-masked]] 
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,

>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.

So, I assume you AGREE with me: it shall be possible to register
different capabilities on different flows?

Regards,

Christer

-----Original Message-----

Hi, 

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 21 Oct 2008 07:38:12 +0200

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-masked]] 
Sent: 20. lokakuuta 2008 23:15
To: Christer Holmberg; SIP IETF
Subject: RE: [Sip] Stupid question on flow use in outbound

Hi Christer, 

Cheers, 
Milo 

-----Original Message----- 
From: Christer Holmberg [mailto:[email-masked]
<mailto:[email-masked]> ] 
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, 

Regards, 

Christer 

-----Original Message----- 
From: [email-masked] [mailto:[email-masked]
<mailto:[email-masked]> ] 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, 

Regards, 

Christer 

<https://www.ietf.org/mailman/listinfo/sip>

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 21 Oct 2008 09:43:57 +0200

Hi, 

super-fast-broadband access for video, you would also have to do your
related SIP transactions over the same interface. In 
>general this is not true, as you could as well run SIP over your
jungle-drum interface while putting the broadband interface addresses in
your SDP. 
confused if you try the media from a different IP address from where you
do SIP (although if you have something like a 
>carrier grade NAT between the UA and the B2BUA there is no guarantee
that SIP and RTP would come from the same IP). Perhaps it would be good
enough to use two different instance id's?

It doesn't have to be a B2BUA. It can be any kind of "gate control node"
which will not allow media to pass unless there is an associated SIP
session. 

Regards,

Christer

>ext Christer Holmberg
>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.
>
>that I want to receive incoming video calls over my 
>"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

---

From: [email-masked] (Juha Heinanen)
Date: Tue, 21 Oct 2008 10:52:13 +0300

> which will not allow media to pass unless there is an associated SIP

then it is the problem with that "gate control node".  of course, it
must be possible to use different ip address for sip and media.

-- juha

---

From: <[email-masked]>
Date: Tue, 21 Oct 2008 10:54:46 +0300

Hi,

Christer Holmberg wrote:
>confused if you try the media from a different IP address from 
>where you do SIP (although if you have something like a 
>that SIP and RTP would come from the same IP). Perhaps it 
>would be good enough to use two different instance id's?
>
>which will not allow media to pass unless there is an 
>associated SIP session. 
>

Yes, but I think such a node will need some information about SIP
sessions and that is given by a B2BUA-ish element (since it needs to dig
into SDP). But OK, the bottom line is that some folks claim they want to
deploy SIP in such a way that media and signaling are strongly
associated like that. Do you know if a lot of them are *really* doing it
too?

Markus

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 21 Oct 2008 09:59:48 +0200

Hi, 

session.

I was referring to the case when signalling and media is transported on
completely different access networks, via different B2BUA/gates/etc.

If signalling and media is transported on the same access networks, they
can in many cases have different IP address and/or port.

Regards,

Christer

---

From: [email-masked] (Juha Heinanen)
Date: Tue, 21 Oct 2008 11:15:25 +0300

> can in many cases have different IP address and/or port.

they should be able to use different access networks too.  that kind of
restriction cannot be placed on any sip protocol component.  if someone
wants to deploy such gates, they better buy ones that talk to each
other.  there is nothing new in this.

-- juha

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 21 Oct 2008 13:28:57 +0200

>>I was referring to the case when signalling and media is transported
on  > completely different access networks, via different
B2BUA/gates/etc.
>>
>>If signalling and media is transported on the same access networks,
they  > can in many cases have different IP address and/or port.
>they should be able to use different access networks too.  that kind of
restriction cannot be placed on any sip protocol component. 

Yes, it can :)

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 21 Oct 2008 13:41:29 +0200

Hi, 

>>>confused if you try the media from a different IP address from where 
>>>you do SIP (although if you have something like a
>>It doesn't have to be a B2BUA. It can be any kind of "gate control 
>>node" which will not allow media to pass unless there is an associated
SIP 
>into SDP).

That is what I meant: the node controlling the gate need the SIP/SDP
information in order to open the gates.

But, if the signalling traverses some other node, in another network,
which has no control over the gate where the media is sent, the gates
won't be opened.

So, you need to make sure that the signalling traverses the node which
controls the gates where the media is to be sent.

>But OK, the bottom line is that some folks claim they want to deploy
SIP in such a way that media and signaling are strongly
>associated like that. Do you know if a lot of them are *really* doing
it too?

I don't know. I am just saying that the signalling needs to traverse the
entities which control the gates where the media is to be sent trough.

Regards,

Christer

---

From: [email-masked] (Juha Heinanen)
Date: Tue, 21 Oct 2008 14:48:57 +0300

> controls the gates where the media is to be sent.

which does not mean that media needs to travel the same path or use the
same ip address as signalling.

-- juha

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 21 Oct 2008 13:52:33 +0200

I never said that.

But: if B2BUA-X controls gate-X, and B2BUA-Y controls gate-Y, you need
to make sure both signalling and media reaches X - OR that both media
and signalling reaches Y. 

Regards,

Christer

---

From: [email-masked] (Juha Heinanen)
Date: Tue, 21 Oct 2008 15:00:38 +0300

> and signalling reaches Y. 

yes, unless B2BUA-X and B2BUA-Y talk to each other.  my point is that
you cannot write a sip spec that prohibits signalling and media from
using different paths/ip addresses.

if your environment is such that it will not work, then you have to
configure your UA in such a way that it always uses same path/ip
address.  i don't see how this would be a protocol issue.

-- juha

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 21 Oct 2008 14:09:03 +0200

>
>yes, unless B2BUA-X and B2BUA-Y talk to each other.

Sure.

>my point is that you cannot write a sip spec that prohibits signalling
and media from using different paths/ip addresses.

The initial point was that it should be allowed to register different
capabilities per flow - in case there are use-cases and architectures
where it could be useful.

Regards,

Christer

---

From: [email-masked] (Juha Heinanen)
Date: Tue, 21 Oct 2008 15:26:00 +0300

> where it could be useful.

and how does that relate to which ip addresses UA uses for signaling and
media?  isn't its UAs internal business?

-- juha

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 21 Oct 2008 14:29:36 +0200

Hi, 

>
>and how does that relate to which ip addresses UA uses for signaling
and media? 

I don't know - it wasn't me who brought that up :)

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 21 Oct 2008 09:12:01 -0400

> restriction cannot be placed on any sip protocol component. 

Its hard to argue with that, since there are so many existence proofs. :-(

But I would say "that kind of restriction SHOULD NOT be placed ...".

The end result of that is people with narrow ideas of what they care 
about break the possibility of many interesting and valuable new 
features. Its the "if I can't control it then you can't have it" mentality.

	Thanks,
	Paul

---

From: Dean Willis <[email-masked]>
Date: Tue, 21 Oct 2008 21:21:08 -0500

On Oct 20, 2008, at 9:37 AM, Orsic, Milo (Milo) wrote:

> Hi Christer,
> 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.
>
> alternative contact addresses must be registered with the same  
> feature tags).
>

The English and Chinese counters are different instances, with  
different capabilities tags. They are not the sort of things that  
Outbound considers alternate flows.

Of course, with SIP, you'd be cloned for each counter, with one clone  
put on the elevator, one clone put on on the escalator, and the  
original you discarded into the bit void.

--
Dean