Subject: [sipcore] Draft new: draft-holmberg-sipcore-received-realm-00

From: Christer Holmberg <[email-masked]>
Date: Mon, 10 Dec 2012 10:04:03 +0000

Hi,

We've submitted a new draft, draft-holmberg-sipcore-received-realm-00.txt, which allows network entry points to indicate the preceding network, from where a request is received. The information can be used inside the network, to provide services, routing etc, based on the information. The indication is conveyed as a new Via header field parameter, "received-realm".

In 3GPP, there is currently a use-case where the information is used to provide services within a transit network. Another use-case, also documented in the draft, is transit routing.

http://www.ietf.org/id/draft-holmberg-sipcore-received-realm-00.txt

Regards,

Christer

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 10 Dec 2012 14:08:15 +0100

10 dec 2012 kl. 11:04 skrev Christer Holmberg <[email-masked]>:

> Hi,
>  
> We’ve submitted a new draft, draft-holmberg-sipcore-received-realm-00.txt, which allows network entry points to indicate the preceding network, from where a request is received. The information can be used inside the network, to provide services, routing etc, based on the information. The indication is conveyed as a new Via header field parameter, “received-realm”.
>  

I think using the keyword "realm" here is unfortunate, since it's an important concept in SIP authentication.
From a quick reading, I don't see that you refer to the authentication realm, but introduce "realm" for something
else.

Also, I don't see any comparision with SIP history and why that can't be used. Maybe SIP identity can add a secure
way of handling this situation too.

/O

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 10 Dec 2012 13:28:40 +0000

Hi,

If "realm" is bad wording, that can be changed :)

SIP history (assuming you refer to History-Info), we were thinking about that, but it's is not really the same semantics, and there is no redirection or retargeting taking place in this case.

It would probably be good to add a few words about that, though.

Regards,

Christer

From: Olle E. Johansson [mailto:[email-masked]]
Sent: 10. joulukuuta 2012 15:08
To: Christer Holmberg
Cc: Olle E. Johansson; [email-masked]
Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-received-realm-00

10 dec 2012 kl. 11:04 skrev Christer Holmberg <[email-masked]<mailto:[email-masked]>>:

Hi,

else.

/O

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 10 Dec 2012 11:15:40 -0500 (EST)

> From: Christer Holmberg <[email-masked]>
> 
> We've submitted a new draft,
> draft-holmberg-sipcore-received-realm-00.txt, which allows network
> entry points to indicate the preceding network, from where a request
> is received. The information can be used inside the network, to
> provide services, routing etc, based on the information. The
> indication is conveyed as a new Via header field parameter,
> "received-realm".

It's an interesting question what this "realm" really is.  Currently,
we have History-Info, and we have the Via "received" parameter.  But
it seems clear to me that the real intention is to identify "From
which service provider's network was this request received?"  And that
information is not the same as knowing which particular host it was
received from.

The difficulty I see is that there is no standardizable way of
designating this.  Within any one network, there may be standard
designators of origin networks, but globally there won't be.  This is
in contrast with History-Info and "received", which specify IP
addresses or DNS names, which have global meanings (more or less).

So it seems to me that all that can be standardized is the particular
method for carrying this information and some of its syntax.  It's
really just a private extension to Via that never really needs to
interwork between systems that aren't in one administrative domain.

As written, the draft seems to gloss over this issue; it mentions a
"network realm value" without mentioning that these values are not
standardized.

There are also some interesting security considerations if a host
attaches a fraudulent "received-realm" to a request before forwarding
it to another network...

Dale

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 10 Dec 2012 17:24:13 +0100

> "network realm value" without mentioning that these values are not
It also says "globally unique" - so why not just use a domain or host name?

> attaches a fraudulent "received-realm" to a request before forwarding

The security part was missing... Which is why I hinted at SIP identity.
Use a domain as a globally unique network identifier then sign it.

If the goal is to use it for routing responses to the specific network,
we should look into that issue, but I'm not clear on what the problem to be solved is.

/O

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 10 Dec 2012 16:25:07 +0000

Hi Dale,

> information is not the same as knowing which particular host it was

Correct.

> "network realm value" without mentioning that these values are not

Very good point.

The idea is not to standardize, or to create some kind of registry, where the "network realm values" would be standardized.

In many cases, the value will only be consumed within a network, so the network operator can use whatever values he wants. If there are cases where some interworking is needed, operators need to deal with that as part of their interworking agreement.

> attaches a fraudulent "received-realm" to a request before forwarding

The idea is that the network that receives the request indicates where it came from. Ie it would not need to trust a value coming from the adjacent network, but it would need to be able to verify from where the request comes.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 10 Dec 2012 16:29:21 +0000

Hi,

> It also says "globally unique" - so why not just use a domain or host name?

That is actually the idea :) My appologies if we didn't make it clear.

I am not sure whether the value actually has to be globally unique, as long as it's unique within the network that uses the value.

> we should look into that issue, but I'm not clear on what the problem to be solved is.

That is not the goal. Responses are routed as defined in RFC 3261, and this draft doesn't change that.

Regards,

Christer

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 10 Dec 2012 17:41:22 +0100

> That is not the goal. Responses are routed as defined in RFC 3261, and this draft doesn't change that.

So what is the problem you are trying to solve, Christer?

/O

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 10 Dec 2012 16:54:28 +0000

Hi,

> So what is the problem you are trying to solve, Christer?

To allow the entry point for network X to insert an indication from which network the requests was received, so that other entities (e.g. Application Servers or routing functions) within network X can use the information to make service/routing decisions. Nothing more than that, really :)

In transit networks, services and routing decissions are often applied based on the preceding network (rather than users, as the transit network typically does not have any user information).

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 10 Dec 2012 12:16:07 -0500

[as sipcore co-chair]

While a little discussion on this list won't hurt, IMO it is premature 
to assume that this will be sipcore work. (In fact, the proposed 
mechanism falls outside the scope of sipcore.) It strikes me that this 
subject might be of interest to people who don't follow sipcore closely. 
(If there are any interested in RAI that don't follow sipcore closely.) 
For instance, the people who care about DRINKS and the now closed SPEERMINT.

Also, as often happens, this draft starts with the solution before there 
has been discussion and refinement of the problem.

So, I think this might be more appropriately discussed in DISPATCH, but 
I'll listen to arguments to the contrary.

	Thanks,
	Paul

On 12/10/12 5:04 AM, Christer Holmberg wrote:
> Hi,
>
> We’ve submitted a new draft,
> draft-holmberg-sipcore-received-realm-00.txt, which allows network entry
> points to indicate the preceding network, from where a request is
> received. The information can be used inside the network, to provide
> services, routing etc, based on the information. The indication is
> conveyed as a new Via header field parameter, “received-realm”.
>
> In 3GPP, there is currently a use-case where the information is used to
> provide services within a transit network. Another use-case, also
> documented in the draft, is transit routing.
>
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 10 Dec 2012 12:30:40 -0500

IMHO this would be very very useful. The use cases are well understood. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Christer Holmberg
Sent: Monday, December 10, 2012 11:54 AM
To: Olle E. Johansson
Cc: Dale R. Worley; [email-masked]
Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-received-realm-00

Hi,

>>>>> entry points to indicate the preceding network, from where a 
>>>>> request is received. The information can be used inside the 
>>>>> network, to provide services, routing etc, based on the 
>>>>> information. The indication is conveyed as a new Via header field 
>>>>> parameter, "received-realm".
>>>>
>>>> It's an interesting question what this "realm" really is.  
>>>> Currently, we have History-Info, and we have the Via "received" 
>>>> parameter.  But it seems clear to me that the real intention is to 
>>>> identify "From which service provider's network was this request 
>>>> received?"  And that information is not the same as knowing which 
>>>> particular host it was received from.
>>>>
>>>> designators of origin networks, but globally there won't be.  This 
>>>> is in contrast with History-Info and "received", which specify IP 
>>>> So it seems to me that all that can be standardized is the 
>>>> particular method for carrying this information and some of its 
>>>> syntax.  It's really just a private extension to Via that never 
>>>> really needs to interwork between systems that aren't in one
administrative domain.
>> I am not sure whether the value actually has to be globally unique, as
long as it's unique within the network that uses the value.
>>>> attaches a fraudulent "received-realm" to a request before 
>>>> forwarding it to another network...
>>>
>>> If the goal is to use it for routing responses to the specific 
>>> network, we should look into that issue, but I'm not clear on what the
problem to be solved is.
> So what is the problem you are trying to solve, Christer?

To allow the entry point for network X to insert an indication from which
network the requests was received, so that other entities (e.g. Application
Servers or routing functions) within network X can use the information to
make service/routing decisions. Nothing more than that, really :)

In transit networks, services and routing decissions are often applied based
on the preceding network (rather than users, as the transit network
typically does not have any user information).

Regards,

Christer

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 10 Dec 2012 18:32:02 +0100

> In transit networks, services and routing decissions are often applied based on the preceding network (rather than users, as the transit network typically does not have any user information).

So what's the reason to insert it into the Via header? The benefit is that you get it in the responses, which you  claim you don't need.

Why not a new header, like originating-domain or something else?

/O

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 10 Dec 2012 20:15:44 +0000

Hi Paul,

>mechanism falls outside the scope of sipcore.)

I believe Via header parameters are within the scope of sipcore.

(For example, we did the keep parameter in sipcore.)

>It strikes me that this subject might be of interest to people who don't follow sipcore closely.

In general, I agree with you, and we were thinking about taking it to DISPATCH.

However, as this is only about an indicator, in typical cases inserted and consumed within a network, and it can be done using an existing header field, we thought that it could be taken directly to SIPCORE.

But, community decides :)

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 10 Dec 2012 20:18:50 +0000

Hi,

> Why not a new header, like originating-domain or something else?

Sure, it could also be done using a new header.

Regards,

Christer

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 10 Dec 2012 21:50:21 +0100

> Sure, it could also be done using a new header.

It that's the case, why make it complicated and add it to Via?

Now, is the reason for this that most people and IP address and not domain to via so that it's hard to get the information needed by inspecting the via headers?

I guess I need to read the docs on History-info to find out why you can't use that. A lot of work has been done to create that solution. I must have missed something important. 

/O

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 11 Dec 2012 08:00:56 +0000

Hi,

...

>>>> To allow the entry point for network X to insert an indication from 
>>>> which network the requests was received, so that other entities 
>>>> (e.g. Application Servers or routing functions) within network X can 
>>>> use the information to make service/routing decisions. Nothing more 
>>>> than that, really :)
>>>> 

Why do you think adding it to Via makes it complicated?

However, I'm not religious regarding the solution. If the community thinks a new header field is more suitable, then fine.

> Now, is the reason for this that most people and IP address and not domain to via so that it's hard to get the information needed by inspecting the via headers?

No. The reason is simply that this is a small piece of information, that we think fits into an existing header field.

> I guess I need to read the docs on History-info to find out why you can't use that. A lot of work has been done to create that solution. I must have missed something important. 

Please do - and I'd be more than happy to be proven wrong regarding the usage of H-I :)

But, again, my understanding of H-I is more about recording redirections/retargets, so that receivers of the request will get that information. In my opinion it's different semantics from what we're trying to do with this draft.

Regards,

Christer

---

From: Michael Procter <[email-masked]>
Date: Tue, 11 Dec 2012 11:25:05 +0000

> But, again, my understanding of H-I is more about recording redirections/retargets, so that receivers of the request will get that information. In my opinion it's different semantics from what we'r…

I've reread the rfc4244bis draft this morning, and from my
understanding of your requirements, using H-I seems like a good fit.
Syntactically, we could define a new hi-extension to record the source
information. Semantically, it seems to fit too.  The introduction to
rfc4244bis states it defines H-I:

   to provide a
   standard mechanism for capturing the request history information to
   enable a wide variety of services for networks and end-users.

I don't want to encourage a jump to defining mechanism too early, but
I think it might help explain your requirements if you discussed why
H-I isn't suitable.

Regards,

Michael

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 11 Dec 2012 10:23:35 -0500 (EST)

The question that I do not see an answer for is "Why does this need to
be standardized?"  By the nature of the problem it addresses, the
production and consumption of this indicator will always be within the
same, centrally-administered network.  The administrator of each such
network can choose their own way to indicate the call source.  It may
be advantageous regarding equipment acquisition to have every vendor's
equipment do it the same way, but that is a 3GPP issue, not an
*Internet* issue.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 11 Dec 2012 12:46:07 -0500

> I believe Via header parameters are within the scope of sipcore.

I checked the charter before saying that:

   The SIPCore working group will concentrate on specifications that
   update or replace the core SIP specifications. In this context,
   "update" means replacing or modifying protocol elements in the above
   listed RFCs in ways that would affect most or all implementations of
   those RFCs alone. Extensions to SIP that add new functionality that
   would not be required of all implementations will be done outside of
   this WG. The process and requirements for such extensions are
   documented in RFC 5727, "Change Process for the Session Initiation
   Protocol".

As I read things, even adding a parameter to the Via header can be done 
via a non-standards-track RFC.

> (For example, we did the keep parameter in sipcore.)

Keep (arguably) affected a lot of implementations. I think it was still 
a gray area.

I also think that some of these things can benefit from being discussed 
in SIPCORE because that is where the appropriate expertise is.

> But, community decides :)

SIPCORE hasn't been busy lately. So I don't want to send you away to 
avoid the work in sipcore. :-)

My main point is to get requirements addressed before focus on the 
solution. It is the chosen solution that brought you to sipcore. And I 
think dispatch is a better place to start discussion of the 
requirements. Some of the comments already raised are at that level. 
I've been glad to see them - they are similar to ones that I was going 
to raise.

For the time being, since some discussion has already begun, (and 
because the participation in dispatch and sipcore is largely the same), 
I'm ok with having the discussion continue here.

I would like to hear more about:
- what a "realm" is,
- who names them,
- what the namespace is for them,
- what happens when transiting multiple realms,
- relationship to Trust Domains (RFC 3324)

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 12 Dec 2012 09:38:35 +0000

Hi,

> My main point is to get requirements addressed before focus on the solution. It is the chosen solution that 
> brought you to sipcore. And I think dispatch is a better place to start discussion of the requirements. Some of the comments already raised are at that level. 
> I've been glad to see them - they are similar to ones that I was going to raise.
>
> For the time being, since some discussion has already begun, (and because the participation in dispatch and sipcore is largely the same), I'm ok with having the discussion continue here.
>

Bad wording :) It should really be an indicator identifying the preceding network.

> - who names them,

The network operators that insert and consume them.

> - what the namespace is for them,

Within the network operator that inserts and consumes them.

For example, if you represent my preceding network, I can identity it as pauls.network.com. But, from a protocol perspective there is no need for you to know that I am using that value.

(Of course, for administrative purposes, it may be a good thing if you and I agree on the values as part of our agreement.)

> - what happens when transiting multiple realms,

The requirement is to be able to identify the preceding network. There is no requirement to identity "5 networks down the path", eventhough such information might be present (depending on what information element is used to carry the information).

> - relationship to Trust Domains (RFC 3324)

If e.g. a transit network is going to provide service(s) to the preceding network, there obviously need to be some agreement and trust between them. And, the entry point needs to be able to verify from where a request comes.

But, as far as the indicator itself is concerned, as it is meant to be inserted and consumed within the same network, I see no relationship with Trust Domains.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 12 Dec 2012 09:57:15 +0000

Hi,

> I've reread the rfc4244bis draft this morning, and from my understanding of your requirements, using H-I seems like a good fit.
> Syntactically, we could define a new hi-extension to record the source information. Semantically, it seems to fit too.  The introduction to rfc4244bis states it defines H-I:
>
>   to provide a
> I don't want to encourage a jump to defining mechanism too early, but I think it might help explain your requirements if you discussed why H-I isn't suitable.

Well, my understanding is still that the semantics are different.

History-Info is about recording things that may change in a request, e.g. the target, so that a receiver later can track the history of the request.

The network entry point doesn't change anything in the request. So, there is no need to insert hi-targeted-to-uri, and the hi-index would not represent a request forward or retarget.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 12 Dec 2012 10:00:40 +0000

Hi,

> The question that I do not see an answer for is "Why does this need to be standardized?"  By the nature of the problem it addresses, the production 
> and consumption of this indicator will always be within the same, centrally-administered network.  The administrator of each such network can 
> choose their own way to indicate the call source.  It may be advantageous regarding equipment acquisition to have every vendor's equipment do 
> it the same way,  but that is a 3GPP issue, not an *Internet* issue.

There may be a need for networks outside 3GPP to use a mechanism like this.

And, eventhough only used within a network, as you said there may be boxes of different vendors etc in that network, why it is useful to have a standardized mechanism.

Regards,

Christer

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 12 Dec 2012 10:34:47 -0500 (EST)

> And, eventhough only used within a network, as you said there may be
> boxes of different vendors etc in that network, why it is useful to
> have a standardized mechanism.

In that regard, I think you want to express the concept of the draft
differently.  In a sense, you aren't *standardizing* a syntax and
semantics for a particular parameter, you're *reserving* a particular
parameter name (against future standardization) so that networks (and
their suppliers) can consistently use that parameter name for a
private purpose.

Based on that concept of what the draft is doing, you want to change
the ABNF from:

   via-params =/ received-realm

   received-realm = "received-realm" EQUAL hostname

to:

   received-realm = "received-realm" EQUAL gen-value

That way, private users of "received-realm" aren't constrained in the
syntax that they might choose to use.

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 12 Dec 2012 15:47:39 +0000

Hi,

> syntax that they might choose to use.

I see no harm in having a syntax, but I don't have strong opinion...

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 12 Dec 2012 11:55:04 -0500

> Bad wording :) It should really be an indicator identifying the preceding network.

I don't care about the word "realm". My question is about the concept of 
a "network" that has a name.

Is every node (or perhaps network interface) part of such a network? Can 
a node (ore network interface) be simultaneously part of more than one 
network, or have more than one network name?

> The network operators that insert and consume them.

So the recipient of messages assigns the names based on information 
available to it?

> For example, if you represent my preceding network, I can identity it as pauls.network.com. But, from a protocol perspective there is no need for you to know that I am using that value.

The syntax in the draft says <hostname>. But are these actual registered 
DNS names? Or are these simply arbitrary identifiers that follow the 
syntax of hostnames?

What is the mechanism for assigning these so that all the nodes that are 
assigning and interpreting these do so in a consistent way?

> The requirement is to be able to identify the preceding network. There is no requirement to identity "5 networks down the path", eventhough such information might be present (depending on what info…

It would be good to be clear about that.

> But, as far as the indicator itself is concerned, as it is meant to be inserted and consumed within the same network, I see no relationship with Trust Domains.

Superficially there seems to be some similarity between this and the 
process of inserting and removing asserted identities at trust 
boundaries. ISTM there should be some thought into whether this is 
coincidental or is significant.

I guess you are assuming that the identifier is preserved from a request 
to a response, even if the request traverses several transit networks? 
And even if there is limited trust between those networks?  (Use of Via 
implies this. This might be necessary in case a network needs to apply 
some services to a response.)

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 12 Dec 2012 20:05:00 +0000

Hi,

> a "network" that has a name.

It's simply an identifier.

> network, or have more than one network name?

HOW the entry point identifies the preceding network is outside the scope. It's something that the network operators have to define, and agree upon as part of their interconnect/transit agreement.

> So the recipient of messages assigns the names based on information available to it?

Correct.

> DNS names? Or are these simply arbitrary identifiers that follow the

They don't have to be actual registered DNS names, but from my understanding when talking to people that would often be the case. That's also the reason <hostname> is used in the syntax.

But, as commented by Dale, the identifier doesn't have to be a hostname - it can be whatever value. So, if people don't like using <hostname>, we can use e.g. <generic-value>.

> What is the mechanism for assigning these so that all the nodes that are assigning and interpreting these do so in a consistent way?

As the entities that insert (the network entry point) and consume (e.g. an application server) the values are part of the same network, the network operator assigns the values, and configures the affected nodes to use the correct values.

> It would be good to be clear about that.

I agree that it can be more clear. Good point.

> to a response, even if the request traverses several transit networks?

It's not needed (eventhough it may of course happen if a Via header field parameter is used). It only needs to be preserved inside the network that inserts and consumes the value.

> some services to a response.)

If my network doesn't want the succeeding network to know anything about the preceding network (identified by the value), it can of course remove the value before forwarding the request to the succeeding network. It could do that even if there is a trust relationship, as the succeeding network isn't supposed to do anything with the identifier. 

(The succeeding network might then itself insert a value on its own, indicatinig that the request came from my network. But there is no requirement that the succeeding network need to know from where my network got the request).

Regards,

Christer

---

From: Adam Roach <[email-masked]>
Date: Wed, 12 Dec 2012 14:16:05 -0600

> They don't have to be actual registered DNS names, but from my understanding when talking to people that would often be the case. That's also the reason <hostname> is used in the syntax.

What I'm seeing here is that these identifiers are only going to be of 
use in conjunction with bilateral agreements between peering partners. 
If that's the case, couldn't such partners collude to use FQDNs in the 
"host" production of Via header fields?

Via: SIP/2.0/TCP 
p24-i379-c1054.foobarcom.net;branch=Z9hG4bK3cGRRPtc;received=192.0.2.26

It's pretty clear that any message containing that Via header field 
transited foobarcom.net at some point during its journey. And that's 
what you're trying to do here, right?

/a

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 13 Dec 2012 08:40:54 +0000

Hi Adam,

> What I'm seeing here is that these identifiers are only going to be of use in conjunction with bilateral agreements between peering partners. 
> If that's the case, couldn't such partners collude to use FQDNs in the "host" production of Via header fields?
>
> Via: SIP/2.0/TCP p24-i379-c1054.foobarcom.net;branch=Z9hG4bK3cGRRPtc;received=192.0.2.26
>
> It's pretty clear that any message containing that Via header field transited foobarcom.net at some point during its journey. And that's what you're trying to do here, right?

I was asking the same thing, and there are couple of issues:

First, in many cases entities insert IP addresses, instead of FQDNs. And, especially in case of enterprise networks things like Inverse DNS won't work.

Second, it requires more processing when the consuming entities need to scan through the list of Via headers, perform "string compares" until it finds the first Via FQDN that doesn't represent a node within its own network, rather than simply looking for the parameter.

So, from a protocol perspective I agree with you that it probably could be done already, and that receive-realm is more about an optimization: one entity does the "hard work", inserts the indicator, and other entities within the network can then simply use it.

Regards,

Christer

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 17 Dec 2012 18:21:47 +0000

A mechanism for this already exists, and has been in fairly wide deployment for many years: the trunk-group/trunk-context identifiers in RFC 4904.

The advantages of doing it as a trunk-context param instead of a Via-header param is that (1) it can be used to indicate the ingress domain info regardless of whether it came in on SIP, H.323, WebRTC, or TDM, and (2) does not require the pass-through or creation of an extra Via header if the ingress node is a B2BUA such as an SBC.

The downside is that it requires adding the tgrp/trunk-context params to the Contact URI, which is a no-no for a SIP Proxy to do.

-hadriel

On Dec 10, 2012, at 5:04 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Regards,

Christer

_______________________________________________
sipcore mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sipcore

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 17 Dec 2012 18:28:59 +0000

Hi,

> The advantages of doing it as a trunk-context param instead of a Via-header param is that (1) it can be used to indicate the ingress domain info regardless 
> of whether it came in on SIP, H.323, WebRTC, or TDM, and (2) does not require the pass-through or creation of an extra Via header if the ingress node is a B2BUA such as an SBC.

The idea is that the ingress node inserts the value, so pass-through is not an issue.

> The downside is that it requires adding the tgrp/trunk-context params to the Contact URI, which is a no-no for a SIP Proxy to do.

Correct. In addition, the request might traverse multiple networks, each with its own ingress node - which would have to remove any existing Contact value, and insert a new one.

It was suggested in 3GPP to use a feature-capability indicator for this, but that suggestion was not accepted as it is not about indicating support for a feature.

Regards,

Christer

Hi,

Regards,

Christer

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 17 Dec 2012 18:54:11 +0000

> The idea is that the ingress node inserts the value, so pass-through is not an issue.

Ah, I missed the part of it adding it to its own Via, rather than the received Via.

> Correct. In addition, the request might traverse multiple networks, each with its own ingress node - which would have to remove any existing Contact value, and insert a new one.

Actually, I think that's a benefit of trunk-group... you've stated the context info is only relevant to the local domain, so passing it on to other domains makes no sense.  Right?  But if it *is* important/useful to pass onto other downstream domains, then putting it in the Via won't work because of downstream B2BUAs removing Via's (as they should).

Don't get me wrong - I've always hated that trunk-group stuff is in the Contact URI - but it's a working solution that's been used successfully for a long time.  Do you think there's sufficient cause/issues/demand to provide yet another way to do the same thing? (I don't know if there is/isn't, just asking)
If there is, I suggest this be done following the trunk group syntax exactly, so that "interworking" it only requires blind copying from one header/URI location to another.  In fact, maybe this thing should be an update to RFC 4904.

-hadriel

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 17 Dec 2012 19:07:34 +0000

Hi,

> Ah, I missed the part of it adding it to its own Via, rather than the received Via.

The example flow shows the difference, but having more normative text about the difference would probably be useful :)

Another reason we chose adding the value to its own Via was to allow e.g. a PSTN gateway (or any other entity that doesn't receive a SIP request with Via headers) to use the mechanism.

> Actually, I think that's a benefit of trunk-group... you've stated the context info is only relevant to the local domain, so passing it on to other domains makes no sense.  Right?

Correct.

> But if it *is* important/useful to pass onto other downstream domains, then putting it in the Via won't work because of downstream B2BUAs removing Via's (as they should).

Correct. But, there are no requiements to pass this information onto other downstream domains.

> Don't get me wrong - I've always hated that trunk-group stuff is in the Contact URI - but it's a working solution that's been used successfully for a long time.  Do you think there's sufficient 
> cause/issues/demand to provide yet another way to do the same thing? (I don't know if there is/isn't, just asking)

I'm not sure it's the same thing. Couldn't the trunk-group (as defined in RFC 4904) be something that you actually want to pass on to downstream domains?

> If there is, I suggest this be done following the trunk group syntax exactly, so that "interworking" it only requires blind copying from one header/URI location to another.  In fact, maybe this thi…

I'm not religious when it comes to the syntax.

Regards,

Christer