Re: [sipcore] #41: Why does only "mp" have a value?

I don't see  what adding another level in the case of mp buys you.  In
the example (and the usual rule) is that you find the entry with "rc"
and you know that the "origin" (as Dale calls it) is the entry just
prior - that's why you don't need an additional index for "rc".   I
don't see that you would mistake this for Carol since the entry prior
to the last entry labeled "rc" does not have a tag and thus you go up
to the parent to find the original target of the request for that
branch.

However, I can see that it could facilitate things to add an index for
the "rc"  just so you can more easily find the entry.  Does anyone
have a problem with that.

Mary.

On Tue, Aug 31, 2010 at 7:50 PM, Hadriel Kaplan <HKaplan@acmepacket.com> wrote:
>
> Uh oh... I think your example shows another problem too.
>
> Suppose atlanta proxy gets a request for Bob as you show, and for Bob it internally has 2 potential routes.  It tries the first, and gets diverted to Carol, as in your example... but Carol fails.  So the atlanta proxy recurses the failure and tries the second route, which is still for *Bob*.  The UAS will get this:
> History-Info: <sip:bob@example.com>;index=1
> History-Info: <sip:bob@example.com>;index=1.1
> History-Info: <sip:carol@example.com>;index=1.2;mp=1.1
> History-Info: <sip:carol@192.0.2.3>;index=1.3;rc
> History-Info: <sip:robert@ssp.net>;index=1.4
> History-Info: <sip:user@192.168.1.1>;index=1.4.1;rc
>
> If you receive that as a UAS, you don't know whether it was diverted to Carol and then reached you as being for Carol, or whether it's back to being for Bob.
> Ugh.
>
> It's a hack, but perhaps a diversion/"mp" should cause a new sub-level.  Like this:
> History-Info: <sip:bob@example.com>;index=1
> History-Info: <sip:bob@example.com>;index=1.1
> History-Info: <sip:carol@example.com>;index=1.1.1;mp=1.1
> History-Info: <sip:carol@192.0.2.3>;index=1.1.2;rc
> History-Info: <sip:robert@ssp.net>;index=1.2
> History-Info: <sip:user@192.168.1.1>;index=1.2.1;rc
>
>
> -hadriel
>
>
> On Aug 31, 2010, at 2:28 PM, sipcore issue tracker wrote:
>
>> #41: Why does only "mp" have a value?
>> ---------------------------------+------------------------------------------
>> Reporter:  worley@…             |       Owner:
>>     Type:  enhancement          |      Status:  new
>> Priority:  critical             |   Milestone:  milestone1
>> Component:  rfc4244bis           |     Version:
>> Severity:  In WG Last Call      |    Keywords:
>> ---------------------------------+------------------------------------------
>> There seems to be no reason to restrict the "mp-value", the information
>> regarding the predecessor request-URI to a newer request-URI, to only "mp"
>> mappings.  In particular, if a redirect server implements an "rc" mapping,
>> it could be difficult for the UAS to determine why it received the
>> request:
>>
>> {{{
>>    Alice   atlanta.example.com  biloxi.example.com   Carol
>>    |                |                |                |
>>    |   INVITE sip:bob@example.com    |                |
>>    |--------------->|                |                |
>>    | History-Info: <sip:bob@example.com>;index=1      |
>>    |                |                |                |
>>    |                |   INVITE sip:bob@example.com    |
>>    |                |--------------->|                |
>>    | History-Info: <sip:bob@example.com>;index=1      |
>>    | History-Info: <sip:bob@example.com>;index=1.1    |
>>    |                |                |                |
>>    |                |   300          |                |
>>    |                |   Contact: <sip:carol@example.com>;mp
>>    | History-Info: <sip:bob@example.com>;index=1      |
>>    | History-Info: <sip:bob@example.com>;index=1.1    |
>>    |                |<---------------|                |
>>    |                |                |                |
>>    |                |   INVITE sip:carol@example.com
>>    |                |--------------->|                |
>>    | History-Info: <sip:bob@example.com>;index=1      |
>>    | History-Info: <sip:bob@example.com>;index=1.1    |
>>    | History-Info: <sip:carol@example.com>;index=1.2;mp=1.1
>>    |                |                |                |
>>    |                |   300          |                |
>>    |                |   Contact: <sip:carol@192.0.2.3>;rc
>>    | History-Info: <sip:bob@example.com>;index=1      |
>>    | History-Info: <sip:bob@example.com>;index=1.1    |
>>    | History-Info: <sip:carol@example.com>;index=1.2;mp=1.1
>>    |                |<---------------|                |
>>    |                |                |                |
>>    |                |   INVITE sip:carol@192.0.2.3    |
>>    |                |-------------------------------->|
>>    | History-Info: <sip:bob@example.com>;index=1      |
>>    | History-Info: <sip:bob@example.com>;index=1.1    |
>>    | History-Info: <sip:carol@example.com>;index=1.2;mp=1.1
>>    | History-Info: <sip:carol@192.0.2.3>;index=1.3;rc |
>>    |                |                |                |
>> }}}
>>
>> (In this case, Carol might know to look for sip:carol@example.com and
>> trace its origin, but if we add a further retargeting and registration
>> lookup cycle for a different user in the middle, we can defeat that
>> strategy.)
>>
>> It would seem useful to allow the "rc" parameter to have a value as well.
>> And given that some 3xx Contacts will have neither "mp" or "rc", but the
>> "origin" value would still be useful for a UAS to see, it seems desirable
>> to split off the "origin" value to another parameter which would be
>> applied regardless of whether "mp" or "rc" applies.
>>
>> --
>> Ticket URL: <http://trac.tools.ietf.org/wg/sipcore/trac/ticket/41>
>> sipcore <http://tools.ietf.org/sipcore/>
>>
>> _______________________________________________
>> sipcore mailing list
>> sipcore@ietf.org
>> https://www.ietf.org/mailman/listinfo/sipcore
>
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
>