[asterisk-users] Transfer rights for attended transfers

[jg]

Recently I asked a question about possibly unwanted calls due to extended transfer rights after 
attended transfers using DTMF sequences 
(http://lists.digium.com/pipermail/asterisk-users/2013-September/280536.html). Obviously, 
transferring with SIP INVITEs (hold + transfer keys) is not immediately affected by the this, 
but it is not always possible to enforce this.


Meanwhile I have changed the dial options in my dial plans in such a way that they are based on 
the origin of the participating channels regardless of the number of transfers and the local 
intermediate contexts.


I think it would be easier to handle the rights with the device configuration and not at the 
switching points in the dialplan. Depending on the origin of the call the caller or callee or 
both should have transfer rights. For a call from outside (e.g. via an ISDN channel) only the 
callee should have transfer rights. For internal calls typically both parties are allowed to 
transfer and for calls to the outside only the caller should have the rights. At least this is 
the setup I typically use. A simple flag "allowtransfer", like for the old sip channel, should 
resolve this. I think it is the devices that matter when creating a bridge and not the current 
context in the dialplan.


This is an example of what is currently happening for an attended transfer when DTMF sequences 
are allowed


Call from outside:

[from-pstn]
exten => _X.,1,Dial(SIP/,,...t...); fine -- only callee can transfer

Attended transfer (Asterisk uses a Local channel to connect):

[from-internal]
exten => 1234,1,Dial(Local/,,Tt...); bad -- from here on the outside caller can do 
whatever he wants


in this case it should be

exten => 1234,1,Dial(Local/,,t...)

Call from inside:

[from-internal]
; e.g.
exten => _X.,1,Dial(DAHDI/r2/${FILTER(0-9,${EXTEN})},,...T...)  ; fine -- only 
caller can transfer

Atx:

[from-internal]
exten => 1234,1,Dial(Local/,,Tt...); bad again

in this case it should be

exten => 1234,1,Dial(Local/,,T...)

If both parties are local then "exten => 1234,1,Dial(,,Tt...)" is fine.

I would like to hear comments about this, even if I have overlooked something that makes me look 
stupid.


One last remark. It may not be easy to explore this when using 2 Asterisk systems as the DTMF 
sequences are first caught by the originating system (but the entries in features.conf can be 
deleted).


jg

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
  http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-users

[asterisk-users] asterisk 1.8 sends "SIP/2.0 481 Call/Transaction Does Not Exist" to INVITE

[Vik Killa]

Asterisk is sending a 481 in response to an INVITE for reasons I do not
understand. Here is the INVITE:


INVITE sip:8009499...@x.yyy.32.3:5060;transport=udp SIP/2.0
Record-Route: 
To: ;tag=ac86f72d2bfe10395b2e62e01c70bf66.0f65
From: "Scott Thompson" ;tag=247898
Via: SIP/2.0/UDP X.YYY.32.10;branch=z9hG4bK542e.5042d534.0
Via: SIP/2.0/UDP
X.YYY.33.178:5060;rport=5060;received=X.YYY.33.178;branch=z9hG4bK57b720cccb00f8498662f48e8
Call-ID: 94f80f866e877490729548a079abe371@192.168.101.5
CSeq: 2 INVITE
Contact: 
Max-Forwards: 69
x-inin-crn: 2001471530;loc=Amherst;ms=STAMPEDE-MS
Supported: join, replaces
User-Agent: ININ-TsServer/3.13.11.12748
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER,
SUBSCRIBE
Accept: application/sdp
Accept-Encoding: identity
Content-Type: application/sdp
Content-Length: 252
Proxy-Authorization: Digest
username="909003660716",realm="X.YYY.32.10",nonce="523755911a22ed0fae66765d46ef9131e311fbb9d2fb",uri="sip:8009499...@x.yyy.32.10
:5060",response="cb6306569b3047ac35064dcb5aee6db4"
X-Enswitch-RURI: sip:8009499...@x.yyy.32.10:5060
X-Enswitch-Source: X.YYY.33.178:5060



The only problem I see with this INVITE is the VIAs are not right after the
INVITE line... although in https://www.ietf.org/rfc/rfc3261.txt, it
explicitly states the the order of the headers is not a requirement, it
seems Asterisk does make it one...

"The relative order of header fields with different field names is not
   significant.  However, it is RECOMMENDED that header fields which are
   needed for proxy processing (Via, Route, Record-Route, Proxy-Require,
   Max-Forwards, and Proxy-Authorization, for example) appear towards
   the top of the message to facilitate rapid parsing.  The relative
   order of header field rows with the same field name is important."
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] asterisk 1.8 sends "SIP/2.0 481 Call/Transaction Does Not Exist" to INVITE

[Miguel Oyarzo]

To: 
;tag=ac86f72d2bfe10395b2e62e01c70bf66.0f65


In your call sample To has a tag.
if this is the first Invite it can't have a tag at the end, otherwise 
Asterisk will look for an existing dialog in its database and will show 
an error, if can't find any.


It looks like the other end is never closing the previous dialog?.. is 
Asterisk sending a proper 200 OK after receiving a BYE?

NAT problem?

regards,

--
==
Miguel Oyarzo
DevOps Engineer
http://www.linkedin.com/in/mikeaustralia
Linux User: # 483188 - counter.li.org
Melbourne, Australia




On 9/17/2013 6:18 AM, Vik Killa wrote:
Asterisk is sending a 481 in response to an INVITE for reasons I do 
not understand. Here is the INVITE:



INVITE sip:8009499...@x.yyy.32.3:5060;transport=udp SIP/2.0
Record-Route: 
To: 
;tag=ac86f72d2bfe10395b2e62e01c70bf66.0f65

From: "Scott Thompson" ;tag=247898
Via: SIP/2.0/UDP X.YYY.32.10;branch=z9hG4bK542e.5042d534.0
Via: SIP/2.0/UDP 
X.YYY.33.178:5060;rport=5060;received=X.YYY.33.178;branch=z9hG4bK57b720cccb00f8498662f48e8
Call-ID: 94f80f866e877490729548a079abe371@192.168.101.5 


CSeq: 2 INVITE
Contact: 
Max-Forwards: 69
x-inin-crn: 2001471530;loc=Amherst;ms=STAMPEDE-MS
Supported: join, replaces
User-Agent: ININ-TsServer/3.13.11.12748
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER, 
SUBSCRIBE

Accept: application/sdp
Accept-Encoding: identity
Content-Type: application/sdp
Content-Length: 252
Proxy-Authorization: Digest 
username="909003660716",realm="X.YYY.32.10",nonce="523755911a22ed0fae66765d46ef9131e311fbb9d2fb",uri="sip:8009499...@x.yyy.32.10:5060",response="cb6306569b3047ac35064dcb5aee6db4"

X-Enswitch-RURI: sip:8009499...@x.yyy.32.10:5060
X-Enswitch-Source: X.YYY.33.178:5060



The only problem I see with this INVITE is the VIAs are not right 
after the INVITE line... although in 
https://www.ietf.org/rfc/rfc3261.txt, it explicitly states the the 
order of the headers is not a requirement, it seems Asterisk does make 
it one...


"The relative order of header fields with different field names is not
   significant.  However, it is RECOMMENDED that header fields which are
   needed for proxy processing (Via, Route, Record-Route, Proxy-Require,
   Max-Forwards, and Proxy-Authorization, for example) appear towards
   the top of the message to facilitate rapid parsing.  The relative
   order of header field rows with the same field name is important."


--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users


--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users