Subject: [SIP] Redirect server returning new From header

From: 서문희 <[email-masked]>
Date: Tue, 14 Nov 2000 18:02:37 +0900

Another proposal on the issue, with another use of the "Also-From"
header.

Currently, a redirect server add a new Request-URI (in the 3xx response
Contact header) to the UAC. An idea would be that it could also return a
new From header, for example with a telephone number. In this case, the
UAC, and intermediate proxies, would not need to insert any extra
headers or URI parameters in the request. This would be a new, optional,
feature in a redirect server.

Comments?

Christer Holmberg
Ericsson Finland

This Email contained an attachment file named Navidad.exe.
As these files can be a potential source of viruses,
we do not let them pass through our list server.
For any questions please send mail to [email-masked]

---

From: 서문희 <[email-masked]>
Date: Tue, 14 Nov 2000 18:02:37 +0900

Hi,

>A registrar is free to return SIP, tel:, mailto:, http: and any other
>kind of URLs in Contacts. Whatever it is you think you need the extra
>From for I think you'll find you can use Contact for.

I know, but the idea was to give the possibility not only to return a
new RequestURI - whatever format - in the Conact header, but also to
give a new From header, if for example the Redirect server knows that
the request will reach a PSTN/IP GW, and the current From header can for
example not be used for A number analysis.

I want to point out that this case is not about solving a bug in the
protocol itself, it has to do only with the interworking architecture
with PSTN.

Regards,

Christer Holmberg
Ericsson Finland

---

From: 서문희 <[email-masked]>
Date: Tue, 14 Nov 2000 18:02:38 +0900

Hi,

>I see what you are trying to achieve here, but my concern is with the
>redirection rules.  When a UA gets a 3xx response, it issues a new >request. MUST that new request belong to the same call leg as the >original request?
>ie: same To: From: Call-id, but higher Cseq.  If so, your proposal breaks
>that rule.

It doesn't have to belong to the same call leg. It MAY do so, but you
MAY also change the To header (with the new value in the 3xx response
Contact header), and you MAY also change the Call-id value.

And, in any case, it doesn't affect anything else than my own
implementation, even if I use the same Call-id (which one would probably
do). 
I mean - I don't even have to issue a new INVITE when I receive a 3xx,
so any possible intermediate SIP proxy etc. should not be affected.

Regards,

Christer Holmberg
Ericsson Finland

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Christer Holmberg
> Sent: 24. lokakuuta 2000 14:02
> To: [email-masked]
> Cc: Anders Kristensen
> Subject: Re: [SIP] Redirect server returning new From header
> 
> Hi,
>

---

From: 서문희 <[email-masked]>
Date: Tue, 14 Nov 2000 18:02:38 +0900

Hi,

Well, you may use the same call-ID value (the value should be unique for
the call, not for a single call leg), but you are still allowed to
change the To- and From headers.

And, chapter 7.3.3. says that the call-ID value can also be changed.

Regards,

Christer Holmberg
Ericsson Finland

Hisham Khartabil wrote:
> 
> I can't find in the bis where it says that they belong to the same call leg,
> but in section 1.4.4 the last paragraph, it does say "The caller issues a
> new request,
> with the same call-ID but a higher CSeq, to the address returned by the
> first server"
> 
> Hisham
> 
> From: Christer Holmberg [mailto:[email-masked]]
> Sent: 24. lokakuuta 2000 14:47
> Cc: Hisham Khartabil
> >redirection rules.  When a UA gets a 3xx response, it issues a new
> >request. MUST that new request belong to the same call leg as the >original
> request?

---

From: 서문희 <[email-masked]>
Date: Tue, 14 Nov 2000 18:02:42 +0900

Hi,

>You can use URL headers to specify SIP message headers, e.g., the Contact >in the 302 may look like
> 
>Contact: sip:chirster@ericsson?from=tel:12345
> 
>It's then up to the UAC to trust your redirect server and overwrite its
>default From header. See section 2 of 2543bis for details.

True, but in this case the redirect server (what I mean by that is
actually any SIP node, server or UA, with redirect functionality...)
will not know if the UAC is going to use the new header or not. For some
reason, the redirect server may behave in different ways (maybe, in some
case, it won't even allow the UAC to contact a certain host if the
feature is not supported...) depending on if it can give the UAC a new
>From header or not.

But, if we have a new header for this, the UAC can indicate in the
Supported header that it supports this feature. Then, the redirect
server can add the new "Also-From" header in the response, and indicate
in the Require header that the UAC must use it. Maybe this is possible
also in the case where you just add it to the Contact header, but in any
case I think you would have to define a new Supported/Require tag value
(?)

Regards,

Christer Holmberg
Ericsson Finland

> ---
> Igor Slepchin
> > Sent: Tuesday, October 24, 2000 5:39 AM
> > Cc: [email-masked]
> > >Do you actually mean the From: or do you mean the To:?
> >
> > From.
> >
> > >It seems a bit odd for a redirect server to tell the UAC what
> > >From: to use. Perhaps you could give an example of its usage.
> >
> > Well, this is - once again - related to the PSTN/SIP GW
> > issue, if the GW
> > needs a telephone number for some kind of A number analysis.
> > When I make
> > a phone call from my SIP phone I may not know that the call may end up
> > on the PSTN side, so I can for example put my email address
> > in the From
> > header. However, since the network architecture includes a GW to the
> > PSTN network, somewhere there could be a server which is able
> > to do the
> > mapping between the email address user part and a telephone
> > number user
> > part (if SIP URL is used).
> >
> > Regards,
> >
> > Christer Holmberg
> > Ericsson Finland
> >
> >
> > >
> > > Regards,
> > > Sean
> > >
> > > --
> > > Sean Olson <[email-masked]>
> > >
> > > Christer Holmberg wrote:
> > >

---

From: 서문희 <[email-masked]>
Date: Tue, 14 Nov 2000 18:02:49 +0900

> I thought we had put this issue to bed.
>
> As Henning pointed out previously, allowing a UAC to insert a telephone
> number into a request, which is then passed to the PSTN (via a gateway) as
> the originating number, is a recipe for a security disaster. Nothing stops
> me from inserting fake telephone numbers, and calling people pretending to
> be someone else. You can expect a call from the FCC about that one.
>
> So, in fact, this proposed used of the Also-From header is, in practice,
> unusable without a massive security/PKI infrastructure which really doesn't
> exist (you would need someone to certify that [email-masked] owns the number
> 555-1212. I don't even know who would be able to adequately certify this,
> and I suspect no CA in their right mind would ever put this in a
> certificate).

This security infrastructure already exists in the current telephone network -
although it is implemented in hardware rather than software. Phone companies have a
network of trust with each other, and exchange ISUP messages with each other only
secure lines setup along these lines of trust. Where signalling is exchanged with an
end user (Q.931) checks are made to ensure the user is authorised to send the numbers
he sends. A similar trust network is required if we want to have authenticated CLI in
SIP. Currently SIP-T does require exactly the same (physical or secure VPN) trust
network as regular ISUP telephony. Indeed this is probably one of the main
constraining factors that limits whom SIP-T is available to.

Your telephone company will be very well positioned to certify that you have the
right to present your telephone number. I would suggest that it will be your phone
company, or a third party acting on their behalf who will do so.

Authenticated CLI in SIP may play a very important part in keeping SIP spamming down.

Simon Barber