SPA 122 and NEC pbx: incoming call problem

[Jeangarden99]

                   Hello,
I registered a SPA122 on a SV8100 NEC pbx; the device is correctly registered and can make outgoing calls but it can't receive any calls...
The caller receives the busy tone when calls SPA phone number.
If I register a CISCO IP Phone 303 to the same pbx and using the same SIP account, the phone receives calls correctly, so I suppose it's a SPA122 problem and not a pbx problem...
In attached a Wireshark trace and the SPA122 configuration file.
Can someone help me please ?
Regards,
GIanni

[Daniele Giordano]

reshark trace I see an outgoing call from SPA to NEC. The call seems ok.

The only issue can be in BYE (too many retransmissions). Probably the NEC doesn't understand the RTP Statistics sent from SPA. Try to disable RTP Statistics in BYE.

But I dont see any incoming calls.

Can you add a new trace?

Regards.

[Jeangarden99]

Hello,

the RTP "STATS in BYE" parameter is already set to "NO".

In attached a new trace about the problem.

Regards,

Gianni

[Daniele Giordano]

Your NEC sends INVITE messages also after SPA responses. There is something in SPA response that it doesn't understood.

This is the SPA 122 response:

This is an example response of my SPA 303:

The difference is in Require: 100rel and Allow-Events.

Try to enable SIP 100REL Enable=YES option.

If it doesn't work, probably the NEC doesn't understand Allow-Event.

Let me know what happens.

Regards.

[Jeangarden99]

Hello,

also enabling SIP 100REL the problem still persists.

If I register a SPA303 using the same SPA122 IP account, the incoming call is ok.
In attached two traces: SPA122 and SPA303.

Regards,

p.s. visto che a quanto pare tu sei italiano, possiamo proseguire la discussione in italiano ?

Grazie

Gianni

[Daniele Giordano]

L'unica differenza significativa che vedo nelle risposte e' la presenza degli Allow-Events nei messaggi Informational (100 Trying, 180 Ringing, 1xx in generale) generati dallo SPA122:

Allow-Events: talk, hold, conference

Probabilmente lo hai gia' notato anche tu. Basta confrontare le due tracciature.

Non dovrebbero esserci problemi ma pare che il NEC non digerisca questa notazione. Hai modo di provare altri dispositivi SIP per capire se il problema e' proprio questo?

Puoi provare a disattivare alcune funzioni dello SPA122 per vedere se evita l'inoltro di questo header?

Prova a disattivare la conferenza, l'attesa, ecc.

Saluti.

[Jeangarden99]

Ho messo a OFF tutti i servizi supplementari ma non cambia nulla.

Se registro al NEC un qualsiasi altro apparato IP (es. X-lite, Snom e come sai anche uno SPA303) non ho nessun problema: chiamo e ricevo correttamente.
Ho anche registrato lo SPA122 ad un pabx di un'altra marca e funziona correttamente;

Quindi si tratta di un'incompatibilità tra lo SPA122 e il NEC SV8100; probabilmente come hai detto lo SPA122 invia delle info che il NEC male interpreta.
Altra cosa: quando genero la chiamata interna da un telefono digitale NEC verso lo SPA122, non sento il tono di chiamata ma solo silenzio, non so se questo può aiutarti a capire come risolvere il problema...

Ho provato a chiedere aiuto anche al supporto NEC, vediamo cosa mi rispondono...nel frattempo se ti viene in mente qualche altra prova da fare fammi sapere.

Grazie in anticipo.

Gianni

[Daniele Giordano]

Sono sempre piu' convinto che il problema siano gli Allow-Events. Potresti provare a fare un downgrade del firmware e vedere se sono stati inseriti solo nelle versioni recenti. Sempre che questa operazione non introduca bug fixati nelle ultime release.

Mi sa che dovremo attendere conferme dalla NEC.

Saluti.

[Jeangarden99]

Ho preso un altro SPA122 (nuovo) avente firmware 1.0.2, il difetto è il medesimo.

Su questa versione nel trace non vedo più quella info legata agli Allow-events...qunidi forse il problema è un altro.

Allego il trace, se ti viene in mente altro fammi sapere.

NEC mi ha risposto che per potermi dare aiuto sulla compatibilità con lo SPA122, devo richiedere in modo formale che venga certificato da NEC (lavoro per un'azienda distributore nazionale NEC e CISCO), quindi i tempi si allungheranno di certo...
E' possibile che si tratti di qualche parametro legato ai timer ?

Per il momento grazie

Gianni

[Daniele Giordano]

L'unica altra notazione differente e' nel SIP TO header che non contiene user=phone.

Per capire se la causa e' questa puoi provare a fare delle altre tracciature usando client X-Lite e Snom.

Nelle release notes dei telefoni SPA5xx ho trovato questo appunto:

user=phone Syntax in a SIP Message

When a tel URL is converted to a SIP URL and the telephone number is

represented by the user portion of the URI, the SIP URL includes the optional

:user=phone parameter (RFC3261). For example:

To: sip:+12325551234@example.com;user=phone

The requirement adds a new parameter under the respective Line SIP Settings to

add:

User=phone ( Yes/No )

The default value is No.

Non mi sembra che questa feature sia stata implementata nelle ATA. Se il problema fosse questo sara' necessario aprire un case alla STAC.

Saluti.

[Jeangarden99]

Ciao,

in allegato un trace fatto con EyeBeam usando lom stesso IP account dello SPA122.

Il tutto funziona correttamente.

Nel caso tu abbia scovato il problema, come si fa ad aprire un case alla STAC visto che non l'ho mai fatto ?

Grazie

Gianni

[Daniele Giordano]

Non ci siamo ancora. Nel trace con EyeBeam non e' presente la notazioen user=phone quindi non e' nemmeno questo.

Non hai modo di attivare un debug SIP sul NEC cosi' campiamo al volo il problema?

[Jeangarden99]

Di seguito il debug fatto tramite il pabx, non so se riesci ad interpretarlo....purtroppo alcuni valori sono in esadecimale, non ho esperienza su questo tipo di attività; se vedi qualcosa di anomalo fammi sapere. Grazie

v7IpTrRxProcess:rcvmsg(4H,f000H,d81bH,3H,4d79c6cH,0H)

*** ring_tone_req (L:D81B,P:3,T:0,D:401) ***

createCallRefIp():4H

voipuDspInfo::reserve() dump search Table

0 1 1 1 1 1 1 1 1 End Dump

voipuDspInfo::reserve() start channel [slot:1,channel:0]

voipuDspInfo::PortLimitCheck:g723mode(0),srtp_mode(0),plr_mode(0)

voipuDspInfo::reserve():logical(d81b),slot(1),channel(1),mode(1)

setCallRefIp(d81b,4,1)

SP_GET_CALLING_PARTY_NUMBER:FAULT task_info.data_w is 0

SAVE_SP_SERIAL(d81b [00060022] -> 001b

SP_CREATE_CALLED_NO :

2 2 6 0 0 0 0 0

*[TRDQUE], P1:d81bH, P2:500d2f0H, P3:0401H, P4:0000H, P5:0000H, P6:0000H

>>>> Status IP(1): 0000H -> 0005H

v7IpTrRxProcess:rcvmsg(2H,0H,1bH,500d600H,0H,0H)

H323 MSG : 02H

>>>> Status IP(1): 0005H -> 0008H

ipCallInfoList::clearRcvMsg() clear rcv msg Pointer 80cbac8H

out_of_range_service(SV8100) : src - D81B, des - 401

*** OUT OF RANGE TIMER FIX ***

vau_play_out_of_range_msg  port:0401 STA

VAU NOT_DEFINED!!

*** ring_tone_req (L:D81B,P:0,T:0,D:0) ***

*[TRDQUE], P1:d81bH, P2:500d2f0H, P3:0000H, P4:0000H, P5:0000H, P6:0000H

>>>> Status IP(1): 0008H -> 000BH

cmain.cpp(3949) Clear RGT Port     : Port    = d81b  Rgt Port = 0

cmain.cpp(3951) Clear RGT des Port : Port = d81b  Rgt des Port = 0

v7IpTrRxProcess:rcvmsg(2H,0H,1bH,500d600H,0H,0H)

H323 MSG : 0AH

*[TRDQUE], P1:d81bH, P2:500d2f0H, P3:0000H, P4:0000H, P5:0000H, P6:0000H

clearCallRefIp(d81b)

>>>> Status IP: disappeared

ipCallInfoList::clearRcvMsg() clear rcv msg Pointer 80cc208H

voipuDspInfo::release():logical(d81b)

cmain.cpp(3949) Clear RGT Port     : Port    = 401  Rgt Port = 0

cmain.cpp(3951) Clear RGT des Port : Port = 401  Rgt des Port = 0

[Daniele Giordano · Accepted solution]

I log non sono esattamente di facile lettura. Vedo un

SP_GET_CALLING_PARTY_NUMBER:FAULT

che potrebbe avere un significato ma non me lo spiego.

Ho riconfrontato i messaggi di uno SPA303 con lo SPA122:

SPA303_OK

Status-Line: SIP/2.0 180 Ringing

Message Header

To: <226>93>;tag=d1be0d61d79b398bi0

From: "GIANNI"<200>;tag=40503246313536410000533B

Call-ID: 020289DCC781400000000004@192.168.177.160

CSeq: 1 INVITE

Via: SIP/2.0/UDP 192.168.177.160:5070;branch=z9hG4bK8865B851F1A24846

Contact: "226" <226>93:5060>

Server: Cisco/SPA303-7.4.9c

Content-Length: 0

SPA122_KO

Status-Line: SIP/2.0 180 Ringing

Message Header

To: <226>187>;tag=e2fa676e9ab1a8efi0

From: "GIANNI"<200>;tag=D94932463135364100027C20

Call-ID: 02028A28628140000000000C@192.168.177.160

CSeq: 1 INVITE

Via: SIP/2.0/UDP 192.168.177.160:5070;branch=z9hG4bK9F3760FE2A28B38B

Contact: "226" <226>187:5060>

Server: Cisco/SPA122-1.0.2(006)

Content-Length: 0

Oltre ad alcune differenze ovvie come gli indirizzi IP, il call-id, i tag ed il branch, cambia chiaramente lo user-agent name o server name.

Non mi aspetto che la causa del problema sia questo header ma tentiamo. Forse ha una notazione che non piace al PBX NEC anche se dovrebbe ignorarlo.

Proviamo a non far inviare nulla:

Nella sezione SIP -> SIP Parameters cancelliamo i campi SIP User Agent Name e SIP Server Name.

Fammi sapere. Grazie.

[Jeangarden99]

Non so come dirtelo, te lo dico così in 3 parole: "SEI UN GENIO"

Ho lasciato vuoti quei due campi e ora funziona anche la chiamata in ingresso.

Ti ringrazio per il tempo e l'aiuto che mi hai dato.

Grazie ancora

Gianni