<grin> Gee, thanks :) (About what you did with the grandstreams).
I know there is some sentiment against them, but other than this issue (and
one other one, whereby when a CALLER (not the called-party) puts a call on
hold, they're unable to retrieve it, but only if the phone is configured for
VLAN tagging), we've been able to overcome any problems we've had with them.
In this case, I can hardly blame grandstream, as they're following the
expected behavior. When a call is transferred, it is transferred to
'xxxx'@registered.domain. (where xxxx is the dialed transfer-to number).
The only two places that COULD affect this are the gateway, and the proxy.
I now have people from both camps telling me it's not their problem. Go
figure. Can't say I expected any different. I still maintain that the proxy
is NOT acting consistently. If it receives 'INVITE:4...@voip.royalroads.ca',
it modifies it to 'INVITE:994495@10.60.0.10'. If it receives
'REFER-TO:4...@voip.royalroads.ca', it doesn't modify it. I believe that it
shouldn't matter WHICH operation is received, it should update the URI
consistently.
...Steve...
From: sipx-users-boun...@list.sipfoundry.org
[mailto:sipx-users-boun...@list.sipfoundry.org] On Behalf Of Tony Graziano
Sent: Wednesday, September 07, 2011 4:10 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Transfer troubles : REFER-TO not routed/modified
according to the dialplan
sipx is a proxy. it is not a proxy for another sip system such as an unmanaged
gateway acting as its own domain. the gateway os not part of its framework, so
yeah, we're not agreeing but systemically it (the gateway) is its own entity.
aks patton about a b2bua function on it, that might be what you need to use,
because that way "it" becomes part of the sipx environment. OR use a SBC, or be
more creative.
I know you didn't want to hear about the UA thing, but like ITSP's and
everything else, they are not all equal.
What I didn't tell you is what I did with my first grandstreams (chuckle), may
they rest in piece(s)...
On Wed, Sep 7, 2011 at 5:58 PM, Steve Beaudry
<steve.beau...@royalroads.ca<mailto:steve.beau...@royalroads.ca>> wrote:
Thanks Tony.
You're correct, I would not like to hear 'use Polycom handsets', as the same
issue exists for me using Grandstream, Snom, and Counterpath softphone UAs, but
specifically because I have already deployed over 100 Grandstream handsets in
production, and have another 370 on hand, ready to deploy.
It seems that you and I are at an impasse with a difference of opinion
regarding a SIP Proxy server.
The SipXecs proxy server ALREADY checks REFER-TO requests against the
permissions, to see if a user is ALLOWED to forward to the number attempted,
which is what results in the authentication packets before the REFER-TO is
passed on. It WELL within the scope of the proxy to update/modify the packet
when if forwards the REFER-TO request after it has taken the time and network
packets to challenge and authenticate the transfer request. The SipXecs proxy
does not blindly forward the REFER-TO request, rather it creates a NEW request,
and sends it on.
Adding an SBC, or reconfiguring the Patton to act as a B2BUA, simply to
overcome a single transfer issue, doesn't seem even close to reasonable. You
told me I was over complicating it already :)
Cheers,
...Steve...
From:
sipx-users-boun...@list.sipfoundry.org<mailto:sipx-users-boun...@list.sipfoundry.org>
[mailto:sipx-users-boun...@list.sipfoundry.org<mailto:sipx-users-boun...@list.sipfoundry.org>]
On Behalf Of Tony Graziano
Sent: Wednesday, September 07, 2011 2:41 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Transfer troubles : REFER-TO not routed/modified
according to the dialplan
you don't. you do if you don't have something parsing or rewriting it
correctly., or is incapable of doing it.
sipx is a proxy. if you are connecting as an unmanaged gateway, this should
work fine. at the same tine I ha e seen this dine with older necessary pbx
systems and have not heard of call transfer issues.
you could also set this up as a siptrunk or as a b2bua in the patton with the
patton essentially registering to sipx.
I would not curry favor with you in suggesting to use a polycom handset as the
sipx ua, which is the only way I have seen it done. sometimes the least common.
component (ua) poses the greatest difficulty. you might inquire of patron
whether they can make you a b2ua on the patton to be the middle ma. between
the two systems.
On Sep 7, 2011 5:33 PM, "Steve Beaudry"
<steve.beau...@royalroads.ca<mailto:steve.beau...@royalroads.ca>> wrote:
> You realize that in the case of a dialed call (if a SipXecs user picks up a
> grandstream phone and dials) to 4495, the SipXecs server DOES rewrite the
> headers, and the rules exist on the patton to route the call correctly?
>
> I'm afraid that I don't understand why I should need an SBC simply to handle
> a transfer between two systems, when dialing back and forth between those
> systems works properly.
>
> From:
> sipx-users-boun...@list.sipfoundry.org<mailto:sipx-users-boun...@list.sipfoundry.org>
>
> [mailto:sipx-users-boun...@list.sipfoundry.org<mailto:sipx-users-boun...@list.sipfoundry.org>]
> On Behalf Of Tony Graziano
> Sent: Wednesday, September 07, 2011 2:27 PM
> To: Discussion list for users of sipXecs software
> Subject: Re: [sipx-users] Transfer troubles : REFER-TO not routed/modified
> according to the dialplan
>
>
> I think its important to say that sipx and sipxbridge as an sbc is designed
> to handle pstn sip trunks.
> I think you expect sipx and an unmanaged gateway to do more than they should.
>
> I do think with the patton handles a refer properly. I don't think id expect
> sipx or the patton to rewrite the header, invite or refer. you would need an
> sbc to do that.
>
> at the same time if 4495 is dialed and sent to the patton I think a match
> rule can be in applied on it to make sure it gets handled properly. i expect
> the patton engineer you are speaking with can probably pull this off.
> On Sep 7, 2011 5:17 PM, "Steve Beaudry"
> <steve.beau...@royalroads.ca<mailto:steve.beau...@royalroads.ca><mailto:steve.beau...@royalroads.ca<mailto:steve.beau...@royalroads.ca>>>
> wrote:
>>
>> Content-Type: text/plain;
>> charset="utf-8"
>> Content-Transfer-Encoding: 8bit
>> Organization: SipXecs Forum
>> In-Reply-To:
>> <CAMgKNJWQao0SctwLUTHgeO610cdARSWkxW22LTgU8n=uyay...@mail.gmail.com<mailto:uyay...@mail.gmail.com><mailto:uyay...@mail.gmail.com<mailto:uyay...@mail.gmail.com>>>
>> X-FUDforum: 08063afcdd00a6e76393c5b9527381e8 <63116>
>> Message-ID:
>> <f68c.4e67d...@forum.sipfoundry.org<mailto:f68c.4e67d...@forum.sipfoundry.org><mailto:f68c.4e67d...@forum.sipfoundry.org<mailto:f68c.4e67d...@forum.sipfoundry.org>>>
>>
>>
>>
>> Hi Tony,
>>
>> So, in reading, re-reading, and re-evaluating things
>> based on what you and others here have said, I think I've
>> realized that the scope of affected transfers is smaller
>> than I thought (although, still critical for us).
>>
>> The issue only occurs when a call comes in through the
>> patton gateway, to a SipXecs extension, which is
>> subsequently transferred/forwarded to an extension that is
>> only reachable back via the Patton gateway. I believe I've
>> seen this referred to as a 'hairpin' call.
>>
>> As you mentioned, you thought the difference (routing
>> looking, and therefore the URI transition) should happen
>> during the INVITE. This certainly works in all cases where
>> the call is initiated on the SipXecs server (ie. using one
>> of the SipXecs registered endpoints), but in this case, the
>> PATTON is responsible for creating the INVITE in response to
>> the transfer, not the SipXecs server. You can see this
>> behaviour at line 521 of the 'External to VoIP DID
>> transferred to Nortel extension.txt' file I attached
>> earlier.
>>
>> The Patton is doing exactly as it is instructed in the
>> REFER-TO request, and attempting to transfer the call to
>> mailto:'4...@voip.royalroads.ca<mailto:4...@voip.royalroads.ca><mailto:4...@voip.royalroads.ca<mailto:4...@voip.royalroads.ca>>'.
>>
>>
>>
>> On the somewhat separate topic of preceeding 4-digit
>> extension numbers with a '99' when dialed, you're right, in
>> hindsight, we could have done without it. This was as much
>> to help with our Nortel dialplan as anything. It does not
>> affect the current issue (the transfer doesn't work if I try
>> to transfer to 994495 either), and I simply pointed it out
>> to give another indication as to where the trouble existed.
>> I should also point out that this works quite well, and is
>> well within the realm of 'correct configuration', done via
>> the standard interface, regardless of whether it's how you
>> would do it or not. It is completely transparent to the end
>> user.
>>
>> What I'm hearing from you is, the SipXecs server does NOT
>> lookup/translate/modify numbers in REFER-TO packets, because
>> it is believed that any translation can be handled during
>> the resulting INVITE. I believe that, in the case of
>> 'hairpin transfers', where the SipXecs server is NOT
>> responsible for creating the INVITE resulting from a
>> REFER-TO, this approach falls short.
>>
>> ...Steve...
>> _______________________________________________
>> sipx-users mailing list
>> sipx-users@list.sipfoundry.org<mailto:sipx-users@list.sipfoundry.org><mailto:sipx-users@list.sipfoundry.org<mailto:sipx-users@list.sipfoundry.org>>
>> List Archive: http://list.sipfoundry.org/archive/sipx-users/
_______________________________________________
sipx-users mailing list
sipx-users@list.sipfoundry.org<mailto:sipx-users@list.sipfoundry.org>
List Archive: http://list.sipfoundry.org/archive/sipx-users/
--
======================
Tony Graziano, Manager
Telephone: 434.984.8430
sip:
tgrazi...@voice.myitdepartment.net<mailto:tgrazi...@voice.myitdepartment.net>
Fax: 434.465.6833
Email: tgrazi...@myitdepartment.net<mailto:tgrazi...@myitdepartment.net>
LAN/Telephony/Security and Control Systems Helpdesk:
Telephone: 434.984.8426
sip: helpd...@voice.myitdepartment.net<mailto:helpd...@voice.myitdepartment.net>
Helpdesk Contract Customers:
http://support.myitdepartment.net
Blog:
http://blog.myitdepartment.net
Linked-In Profile: http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4
Ask about our Internet faxservices!
_______________________________________________
sipx-users mailing list
sipx-users@list.sipfoundry.org
List Archive: http://list.sipfoundry.org/archive/sipx-users/
