Subject: [Sip] SIP refer method

From: "ajay thakur" <[email-masked]>
Date: Thu, 24 Apr 2008 14:34:30 +0530

Hi guys,
I have one doubt related to refer method.

A---------|
           |
           |--------Router-----------------C
B---------|

In the above topology A & B phones are internal phones. C is external phone.

Scenario is A calls C  and then A refers B to C;

So when A sends refer message to C it includes B's SIP URI. Now my doubt is
can we have port number along with this address.

e.g. Refer-To:<sip:xxx@ip-address:port-number>

Thanks
Ajay
_______________________________________________
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: "James M. Polk" <[email-masked]>
Date: Thu, 24 Apr 2008 19:03:27 -0500

>Scenario is A calls C  and then A refers B to C;

If A calls C, the either A or C need to send the REFER to the other, 
telling one of them to contact B.  For example, A calls C, and then A 
sends REFER to C to contact B. C will now send an INVITE to B with a 
Contact: header value of A

>
>So when A sends refer message to C it includes B's SIP URI.

In the Refer-To: header, yes

>Now my doubt is

why not?

---

From: "ajay thakur" <[email-masked]>
Date: Fri, 25 Apr 2008 11:48:30 +0530

James If there is any kind of firewall enabled on Router then connection
from C to B is not allowed. That's what is main worry :(

Ajay

On Fri, Apr 25, 2008 at 5:33 AM, James M. Polk <[email-masked]> wrote:

> telling one of them to contact B.  For example, A calls C, and then A sends
> REFER to C to contact B. C will now send an INVITE to B with a Contact:
> header value of A
>
>

---

From: "Donald Lee" <[email-masked]>
Date: Fri, 25 Apr 2008 17:34:00 +0800

in case there is firewall or like nat issues b/w C and B, the normal REFER
will be failed to enable the C INVITE B.  how the INVITE can be routed to B
correctly?

-- 
BR
Donald

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 25 Apr 2008 11:28:26 -0500

At 04:34 AM 4/25/2008, Donald Lee wrote:
>in case there is firewall or like nat issues b/w C and B, the normal 
>REFER will be failed to enable the C INVITE B.  how the INVITE can 
>be routed to B correctly?
>
>On Fri, Apr 25, 2008 at 2:18 PM, ajay thakur 
><<mailto:[email-masked]>[email-masked]> wrote:

First of all, no one mentioned a firewall in this scenario.

But if there is a firewall, how exactly will the firewall fail the 
SIP request (I know it can be configured to block anything (or 
everything), but is this normally the problem)? Won't SIP perform 
fine, and the problem be a RTP stream issue *IF* there is a NAT involved?

A lot depends on where the firewall (and NAT) are in this A-B-C scenario below.

BTW - check this ID out for answers to NATs (that weren't offered in 
the original scenario):

         Title          : Best Current Practices for NAT Traversal for SIP
         Author(s)      : C. Boulton, et al.
         Filename       : draft-ietf-sipping-nat-scenarios-08.txt
         Pages          : 62
         Date           : 2008-04-25

Traversal of the Session Initiation Protocol (SIP) and the sessions
it establishes through Network Address Translators (NAT) is a complex
problem. Currently there are many deployment scenarios and traversal
mechanisms for media traffic. This document aims to provide concrete
recommendations and a unified method for NAT traversal as well as
documenting corresponding flows.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sipping-nat-scenarios-08.txt

>
>Ajay
>
>On Fri, Apr 25, 2008 at 5:33 AM, James M. Polk 
><<mailto:[email-masked]>[email-masked]> wrote:
>telling one of them to contact B.  For example, A calls C, and then 
>A sends REFER to C to contact B. C will now send an INVITE to B with 
>a Contact: header value of A
>
>
>
>Sip mailing 
>list 
><https://www.ietf.org/mailman/listinfo/sip>https://www.ietf.org/mailman/listinfo/sip
>Use 
><mailto:[email-masked]>[email-masked] 
>for questions on current sip
>Use <mailto:[email-masked]>[email-masked] for new developments 
>on the application of sip
>
>
>
>
>Sip mailing 
>list 
><https://www.ietf.org/mailman/listinfo/sip>https://www.ietf.org/mailman/listinfo/sip
>Use 
><mailto:[email-masked]>[email-masked] 
>for questions on current sip
>Use <mailto:[email-masked]>[email-masked] for new developments 
>on the application of sip
>
>
>
>
>--
>BR
>Donald

---

From: "ajay thakur" <[email-masked]>
Date: Mon, 28 Apr 2008 12:24:53 +0530

James,
I will try to explain problem here.
A---------|
           |
           |--------Router-----------------C
B---------|
On router access list is used to deny incoming calls from outside to
internal network.
A,B are internal network. And C is on WAN side.
Outgoing calls are allowed through access lists.

Now call from A to C works perfectly when A initiates call.
Now when A wants to transfer call to other internal phone (B in this case),
then A sends refer message to C.

Now C tries to connect to B and C uses contact address of B to connect. But
incoming calls from WAN side is not allowed. So what can be done to fix
these kind of problems ?

Thanks
Ajay
On Fri, Apr 25, 2008 at 9:58 PM, James M. Polk <[email-masked]> wrote:

> > REFER will be failed to enable the C INVITE B.  how the INVITE can be routed
> > to B correctly?
> >
> > On Fri, Apr 25, 2008 at 2:18 PM, ajay thakur <<mailto:
> > [email-masked]>[email-masked]> wrote:
> But if there is a firewall, how exactly will the firewall fail the SIP
> request (I know it can be configured to block anything (or everything), but
> is this normally the problem)? Won't SIP perform fine, and the problem be a
> RTP stream issue *IF* there is a NAT involved?
>
> BTW - check this ID out for answers to NATs (that weren't offered in the
> original scenario):
>
> > On Fri, Apr 25, 2008 at 5:33 AM, James M. Polk <<mailto:[email-masked]
> > >[email-masked]> wrote:
> > Sip mailing list <https://www.ietf.org/mailman/listinfo/sip>
> > https://www.ietf.org/mailman/listinfo/sip
> > Use <mailto:[email-masked]>
> > [email-masked] for questions on current sip
> > Use <mailto:[email-masked]>[email-masked] for new developments on
> > the application of sip
> >
> >
> >
> >
> > Sip mailing list <https://www.ietf.org/mailman/listinfo/sip>
> > https://www.ietf.org/mailman/listinfo/sip
> > Use <mailto:[email-masked]>
> > [email-masked] for questions on current sip
> > Use <mailto:[email-masked]>[email-masked] for new developments on
> > the application of sip
> >
> >
> >
> >
> > --
> > BR
> > Donald
> >
>
>

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 28 Apr 2008 10:06:16 -0500

>Outgoing calls are allowed through access lists.

what you describe means C cannot call A or B. This is fine, if you 
want to have a that level of denial, but you will have to live with C 
not being able to call A just the same as A not being allowed to 
transfer C to B.

Something will have to give for C to do anything into the A&B LAN 
segment other than answer a call from either A or B.

>Now when A wants to transfer call to other internal phone (B in this 
>case), then A sends refer message to C.
>
>Now C tries to connect to B and C uses contact address of B to 
>connect. But incoming calls from WAN side is not allowed. So what 
>can be done to fix these kind of problems ?
>
>
>Thanks
>Ajay
>On Fri, Apr 25, 2008 at 9:58 PM, James M. Polk 
><http://www.ietf.org/internet-drafts/draft-ietf-sipping-nat-scenarios-08.txt>http://www.ietf.org/internet-drafts/draft-ietf-sipping-nat-scenarios-08.txt
>
>
>Ajay
>
>
><<mailto:[email-masked]><mailto:[email-masked]>[email-masked]> wrote:
>Sip mailing list 
><<https://www.ietf.org/mailman/listinfo/sip>https://www.ietf.org/mailman/listinfo/sip>https://www.ietf.org/mailman/listinfo/sip 
>
>
><mailto:[email-masked]><mailto:[email-masked]>[email-masked] 
><mailto:[email-masked]><mailto:[email-masked]>[email-masked] 
>for new developments on the application of sip
>
>
>
>
>Sip mailing list 
><<https://www.ietf.org/mailman/listinfo/sip>https://www.ietf.org/mailman/listinfo/sip>https://www.ietf.org/mailman/listinfo/sip 
>
>
><mailto:[email-masked]><mailto:[email-masked]>[email-masked] 
><mailto:[email-masked]><mailto:[email-masked]>[email-masked] 
>for new developments on the application of sip
>
>
>
>
>--
>BR
>Donald
>
>