[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] SIP refer method
At 01:54 AM 4/28/2008, ajay thakur wrote:
>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.
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 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
><<mailto:jmpolk at cisco.com>jmpolk at cisco.com> wrote:
>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:thakur.ajay.ietf at gmail.com>thakur.ajay.ietf at gmail.com> wrote:
>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 :(
>
>
>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>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:jmpolk at cisco.com><mailto:jmpolk at cisco.com>jmpolk at cisco.com> wrote:
>At 04:04 AM 4/24/2008, ajay thakur wrote:
>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;
>
>
>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
>can we have port number along with this address.
>
>
>why not?
>
>
>e.g. Refer-To:<sip:xxx at ip-address:port-number>
>
>
>Thanks
>Ajay
>_______________________________________________
>Sip mailing list
><<https://www.ietf.org/mailman/listinfo/sip>https://www.ietf.org/mailman/listinfo/sip>https://www.ietf.org/mailman/listinfo/sip
>
>
>This list is for NEW development of the core SIP Protocol
>Use
><mailto:sip-implementors at cs.columbia.edu><mailto:sip-implementors at cs.columbia.edu>sip-implementors at cs.columbia.edu
>for questions on current sip
>Use
><mailto:sipping at ietf.org><mailto:sipping at ietf.org>sipping at ietf.org
>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
>
>
>This list is for NEW development of the core SIP Protocol
>Use
><mailto:sip-implementors at cs.columbia.edu><mailto:sip-implementors at cs.columbia.edu>sip-implementors at cs.columbia.edu
>for questions on current sip
>Use
><mailto:sipping at ietf.org><mailto:sipping at ietf.org>sipping at ietf.org
>for new developments on the application of sip
>
>
>
>
>--
>BR
>Donald
>
>
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip