Funciones SIPAddHeader/SIPRemoveHeader en Asterisk 1.8

[Andoni]

Buenas,

Estoy teniendo algunos problemas con el uso de estas dos funciones en
Asterisk 1.8 (SIPAddHeader existe desde la 1.4). A ver si alguien ha
trabajado con esto o ve algo que estoy haciendo mal...

El escenario es sencillo, un simple Originate con ChanLocal desde el
AMI. (Típico ClickToDial)
La idea es que la primera llamada el terminal la auto-responda.

[leg1]
exten => _X.,1,Set(CALLERID(all)="Autollamada" <${EXTEN}
>)
exten => _X.,n,SipAddHeader(Call-Info: \;answer-after=0) ;; Para
autoresponder la llamada
exten => _X.,n,DumpChan()
exten => _X.,n,Dial(SIP/${EXTEN})
exten => _X.,n,Hangup()

[leg2]
exten => _X.,1,Set(CALLERID(num)=${USER})
exten => _X.,n,SIPRemoveHeader()
exten => _X.,n,DumpChan()
exten => _X.,n,Dial(SIP/${EXTEN})
exten => _X.,n,Hangup()


En la primera pata:

Dumping Info For Channel: Local/3200@leg1-4a65;2:
================================================================================
Info:
Name= Local/3200@leg1-4a65;2
Type= Local
UniqueID= 1301563174.453
CallerIDNum= 3200
CallerIDName= Autollamada
.
.
.

Variables:
SIPADDHEADER01=Call-Info: ;answer-after=0
================================================================================


Ok, correcto el primer terminal auto-responde.


En la segunda pata:

Dumping Info For Channel: Local/3200@leg1-4a65;1:
================================================================================
Info:
Name= Local/3200@leg1-4a65;1
Type= Local
UniqueID= 1301563174.452
CallerIDNum= 3200
CallerIDName= (N/A)
.
.
.
Context= leg2
Extension= 3100
.
.

Variables:

================================================================================

Ok, todo parece correcto, pero el segundo terminal también auto-
responde. :(

Traceando veo que:
-Primer INVITE:

U 10.10.0.156:5060 -> 10.10.0.142:5064
INVITE sip:32...@10.10.0.142:5064 SIP/2.0.
Via: SIP/2.0/UDP 10.10.0.156:5060;branch=z9hG4bK0d964291.
Max-Forwards: 70.
From: "Autollamada" <sip:32...@10.10.0.156>;tag=as20d47640.
To: <sip:32...@10.10.0.142:5064>.
Contact: <sip:32...@10.10.0.156:5060>.
Call-ID: 031dd7e37c4a9576...@10.10.0.156:5060.
CSeq: 102 INVITE.
User-Agent: "Irontec IVOZ".
Date: Thu, 31 Mar 2011 09:25:12 GMT.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
INFO, PUBLISH.
Supported: replaces, timer.
Call-Info: ;answer-after=0.
Remote-Party-ID: "Autollamada" <sip:
32...@10.10.0.156>;party=calling;privacy=off;screen=no.
Content-Type: application/sdp.
Content-Length: 248.
.
v=0.
o=root 1752634051 1752634051 IN IP4 10.10.0.156.
s=Asterisk PBX 1.8.2.3 (RSP (Community supported branch) 1.8.2.3).
c=IN IP4 10.10.0.156.
t=0 0.
m=audio 14054 RTP/AVP 8.
a=rtpmap:8 PCMA/8000.
a=silenceSupp:off - - - -.
a=ptime:20.
a=sendrecv.

-Segundo INVITE:

U 10.10.0.156:5060 -> 10.10.0.177:5062
INVITE sip:31...@10.10.0.177:5062 SIP/2.0.
Via: SIP/2.0/UDP 10.10.0.156:5060;branch=z9hG4bK07beac47.
Max-Forwards: 70.
From: "Usuario2 " <sip:32...@10.10.0.156>;tag=as5be1fc8c.
To: <sip:31...@10.10.0.177:5062>.
Contact: <sip:32...@10.10.0.156:5060>.
Call-ID: 6ba3611f0da9c720...@10.10.0.156:5060.
CSeq: 102 INVITE.
User-Agent: "Irontec IVOZ".
Date: Thu, 31 Mar 2011 09:25:13 GMT.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
INFO, PUBLISH.
Supported: replaces, timer.
Call-Info: ;answer-after=0.
Remote-Party-ID: "Usuario2 " <sip:
32...@10.10.0.156>;party=calling;privacy=off;screen=no.
Content-Type: application/sdp.
Content-Length: 246.
.
v=0.
o=root 252750921 252750921 IN IP4 10.10.0.156.
s=Asterisk PBX 1.8.2.3 (RSP (Community supported branch) 1.8.2.3).
c=IN IP4 10.10.0.156.
t=0 0.
m=audio 14088 RTP/AVP 8.
a=rtpmap:8 PCMA/8000.
a=silenceSupp:off - - - -.
a=ptime:20.
a=sendrecv.



Como se ve en el segundo INVITE la cabecera(Call-Info) no ha
desaparecido!!!

Entiendo que en la segunda pata no debería existir esa cabecera ¿¿no??
https://wiki.asterisk.org/wiki/display/AST/Application_SIPRemoveHeader

Pues nada, si alguien ha jugado con esto le agradecería su ayuda.


Un saludo.

[Saúl Ibarra Corretgé]

Aupa,

Si pones un DumpChan *antes* de llamar a SIPRemoveHeader ves que esta
definida la variable de canal SIPADDHEADER ?

--
/Saúl
http://saghul.net | http://sipdoc.net

[Fernando Villares]

epa eso dice ese dialplan como se ve....

--
Este email pertenece a la lista de Asterisk-ES (http://www.asterisk-es.org)

~~~ Normas de la lista Asterisk-ES: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
http://comunidad.asterisk-es.org/index.php?title=Lista:normas-asterisk-es
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- Para anular la suscripción: asterisk-es...@googlegroups.com

[Andoni]

Aupa,

No, no aparecía la cabecera antes del SIPRemoveHeader.

Y... tenías razón, con la opción /n (no la conocía) a la hora de
llamar al ChanLocal todo funciona como debe. (o como yo me esperaba)
Tema resuelto.

Thanks.

[Saúl Ibarra Corretgé]

2011/3/31 Andoni <andoni...@gmail.com>:

> Aupa,
>
> No, no aparecía la cabecera antes del SIPRemoveHeader.
>
> Y... tenías razón, con la opción /n (no la conocía) a la hora de
> llamar al ChanLocal todo funciona como debe. (o como yo me esperaba)
> Tema resuelto.
>

No vayas tan veloz amigo del chan_local! El /n *puede* afectar al CDR.
Ademas, al no hacer el native bridge el rendimiento es peor, aunque en
este caso no importa... Si todo te funka ponle la pegatina de
WorksOnMyComputer (TM) y a molar :-)

En cualquier caso, molaria comentar esto por Asterisk-Dev, huele a bug...

[Andoni]

On 31 mar, 17:39, Saúl Ibarra Corretgé <sag...@gmail.com> wrote:
> 2011/3/31 Andoni <andoni.izu...@gmail.com>:

Aupa,

Sí, sobre el tema del rendimiento ya había leído algo y en este caso
el auto-answer no será la opción por defecto (por tanto el /n
tampoco).
El CDR lo había mirado antes del /n y parecía todo en orden, ¿a que te
refieres con que puede afectar al CDR? :S
Lo miraré mejor.

Voy a ver si hay comentarios al respecto por ahí y si no, lo comento.
A ver que dicen...

[Saúl Ibarra Corretgé]

Aupa!

>
> Sí, sobre el tema del rendimiento ya había leído algo y en este caso
> el auto-answer no será la opción por defecto (por tanto el /n
> tampoco).

Entonces sin problema!

> El CDR lo había mirado antes del /n y parecía todo en orden, ¿a que te
> refieres con que puede afectar al CDR? :S
> Lo miraré mejor.
>

Tengo un recuerdo medio borroso del asunto, pero medio-recuerdo algo
de que _igual_ afectaba al CDR. SI has probado y todo va OK sera que
me equivoco :-)

> Voy a ver si hay comentarios al respecto por ahí y si no, lo comento.
> A ver que dicen...
>

;-)