Subject: Re: [Enum] SIP AoR, tel and ENUM - Second Try

From: "Stastny Richard" <[email-masked]>
Date: Wed, 7 Dec 2005 17:23:52 +0100

Thanx Klaus

Also for answering a question I did not (yet) ask
regarding redirect vs proxy

>I personally prefer relaying instead of redirect.

Me too and I see your arguments.
Are there any arguments out there why to prefer redriect?
 
Richard

________________________________

Von: Klaus Darilion [mailto:[email-masked]]
Gesendet: Mi 07.12.2005 13:39
An: Stastny Richard
Cc: [email-masked]; [email-masked]; [email-masked]
Betreff: Re: [Enum] SIP AoR, tel and ENUM - Second Try

Hi Richard!

comments inline

Stastny Richard wrote:
> Should Infrastructure ENUM contain a routing information
> to the next hop only (the ingress border element of Provider B
> (or administrative domain B)
> or simply a mapping from an E.164 number to an AoR?

IMHO it should be a mapping to an AoR as in user ENUM.

> I will try to give another example and start from
...
> I subscribe with provider B and get a default public
> user identity (AoR) from this provider:
> e.g. sip:[email-masked]
>
> This "foo" can be anything the provider chooses it to be:
> e.g. an alphanumeric string such as ywzabcd,
> a numeric string such as 16241 (my FWD number)
> or 019793321 or 4319793321
>
> Any other provider A having a peering agreement
> with Provider B must be able to route a SIP call
> given this SIP AoR to provider B, either to the
> SIP proxy hosting this account or at least to
> the ingress proxy(s) in provider B network.
>
> On way to do so is to use SRV records within
> the zone of provB.net pointing to e.g
>
> ingress14.provB.net
> and
> ingress21.provB.net
>
> Question: is this correct?

IMO yes. Thus, A sends "INVITE sip:[email-masked]" to ingress14.provB.net

> Note: after the ingress proxy provider B
> may use another mapping mechanism to find
> the real hosting server e.g. srv21.provB.net
>
> Now I as a user are not happy with this default
> public user identity, I want to have some aliases
>
> eg:
> 1)sip:[email-masked] and
> 2) +43 1 9793321
>
> In case 1) I assume that provider B needs
> to provide me with redirect server(s), and I
> need to enter in stastny.com SRV records
> to point to these redirect servers
> e.g. redirect.provB.net
>
> sip:richard.stastny.com is redirected to
> sip:[email-masked]
>
> Question: is this correct?

This is a working scenario. But a redirect server is not mandatory. It
may also be a proxy which forwards the request "INVITE
sip:richard.stastny.com" to "INVITE sip:[email-masked]".

It is also possbile that SRV for stastny.com points directly to
ingress12.provB.net and ingress12 knows about all hosted SIP domains and
knows how to forward the request to the end user.

But this is a design decision of the provB and IMO should be out of
scope of SPEERMINT. provB may use redirect server, provC may accept all
hosted SIP domains directly on their ingress points, .....

I personally prefer relaying instead of redirect. E.g. redirect raises
questions like: How should intercept the redirect response and forward
to the new URI? The UA client or the SIP proxy of provA or the egress proxy?

The important thing is that the originator (provA) should not have to
take care how provB implemented the hosting of SIP domains.

> In case 2) we need Infrastructure ENUM
> [Side note; in my user ENUM I would either enter
> sip:[email-masked] or sip:[email-masked]
> this is my choice]
>
> Now the question is: what goes into Infrastructure
> ENUM for say +4319793321?
>
> Is it:
> Sip:[email-masked] (if plain sip:[email-masked] works
> this must also work)
> OR
> sip:[email-masked];user=phone (correct?)
> OR
> sip:[email-masked] (wrong?)
> OR
> sip:[email-masked] (valid only if 4319793321 = foo)
>
> OR is it
> sip:[email-masked];user=phone (and the above variants)
> AND
> sip:[email-masked];user=phone

IMO all of these are valid. It's up to the choice of provB. provB can
put anything into ENUM as long as provB is able to map from the URI in
I-ENUM to the end user.

If I would design the network for provB, I would use version 2 (without
user=phone as the user are not limited to phones).

> In this last case one would not need to query the
> SRV records in provB.net

Also in the last case (if beeing conform with RFC3263), the egress proxy
has to perform NAPTR and SRV lookups. If you want to avoid them, just
put the IP address or the port into the host part, e.g.

sip:[email-masked]:5060;user=phone

regards
klaus

_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: Klaus Darilion <[email-masked]>
Date: Fri, 09 Dec 2005 12:52:49 +0100

> Are there any arguments out there why to prefer redriect?

I just made some signaling pictures to visualize the difference:
 From the signaling, there is no big difference. Both versions do need 
approximately the same amount of signaling packets sent (depends onthe 
actual SIP network design).

I do not see any technical reason why to prefer one version over the 
other. It's just a personal preference.

regards
klaus

UAC  proxyA  borderProxyA       redirectProxy borderProxyB  proxyB  UAS
|        |          |                  |             |        |      |
|-INVITE>|          |                  |             |        |        |
|<-100---|-INVITE-->|                  |             |        |        |
|        |<--100----|-------INVITE---->|             |        |        |
|        |          |                  |             |        |        |
|        |          |<------302--------|             |        |        |
|        |<-302-----|-------ACK------->|             |        |        |
|        |--ACK---->|                  |             |        |        |
|        |--INVITE->|                  |             |        |        |
|        |<-100-----|--------------INVITE----------->|        |        |
|        |          |<--------------100--------------|-INVITE>|        |
|        |          |                  |             |<-100---|-INVITE>|
|        |          |                  |             |        |<-100---|
|        |          |                  |             |        |        |
|        |          |                  |             |        |<-180---|
|        |          |                  |             |<--180--|        |
|        |          |<---------------180-------------|        |        |
|        |<--180----|                  |             |        |        |
|<--180--|          |                  |             |        |<--200--|
|        |          |                  |             |<--200--|        |
|        |          |<---------------200-------------|        |        |
|        |<---200---|                  |             |        |        |
|<---200-|          |                  |             |        |        |
|        |          |                  |             |        |        |
|--ACK-->|          |                  |             |        |        |
|        |----ACK-->|                  |             |        |        |
|        |          |--------------ACK-------------->|        |        |
|        |          |                  |             |--ACK-->|        |
|        |          |                  |             |        |--ACK-->|
|        |          |                  |             |        |        |
|        |          |                  |             |        |        |
|        |          |                  |             |        |        |

32 Packets

UAC   proxyA  borderProxyA       forwardProxy  borderProxyB  proxyB  UAS
|        |          |                  |             |        |        |
|-INVITE>|          |                  |             |        |        |
|<-100---|-INVITE-->|                  |             |        |        |
|        |<--100----|-------INVITE---->|             |        |        |
|        |          |<-------100-------|---INVITE--->|        |        |
|        |          |                  |<----100-----|-INVITE>|        |
|        |          |                  |             |<-100---|-INVITE>|
|        |          |                  |             |        |<-100---|
|        |          |                  |             |        |        |
|        |          |                  |             |        |<-180---|
|        |          |                  |             |<--180--|        |
|        |          |                  |<---180------|        |        |
|        |          |<----- -180-------|             |        |        |
|        |<--180----|                  |             |        |        |
|<--180--|          |                  |             |        |<--200--|
|        |          |                  |             |<--200--|        |
|        |          |                  |<---200------|        |        |
|        |          |<-------200-------|             |        |        |
|        |<---200---|                  |             |        |        |
|<---200-|          |                  |             |        |        |
|        |          |                  |             |        |        |
|--ACK-->|          |                  |             |        |        |
|        |----ACK-->|                  |             |        |        |
|        |          |--------------ACK-------------->|        |        |
|        |          |                  |             |--ACK-->|        |
|        |          |                  |             |        |--ACK-->|

29 Packets