UC540 y extraño problema con Multisite

[John Martin]

Buenas a todos.

Tengo un problema que aun no tengo claro que es, aunque despues de leer varias horas documentos empiezo a pensar cual puede ser el problema, pero necesito confirmarlo.

Tenemos dos UC540 SItio A (81...)<-------------------------------------------> Sitio B (82...)

Si se realizan llamadas entre sitios, no hay problemas.

Si se realizan llamadas a grupos en el mismo sitio o enle otro, no hay problemas.

Si entra una llamada desde el SipTrunk a un telefono DE UN SITIO o a un grupo de un SITIO, no hay problemas. Pero si entra una llamada desde el Sip Trunk ( las llamadas las gestiona el SITIO A ) y hago soñar los telefonos de los dos sitios, si cojen la llamada desde el SITIO B, no hay problema, pero si cojen la llamada desde el SITIO A, no hay audio. El Sip Trunk solo acepta el codec g711Alaw.

UC540_FACT# show voice call status
CallID CID ccVdb Port Slot/DSP:Ch Called # Codec MLPP Dial-peers
0x6 11F5 0x88FC6030 50/0/9.0 ABC g711ulaw 20001/5
0x7 11F5 0x885BA478 0/4/0 0/1:1 *ABC g711ulaw 5/20001
0x13C9 24C7 0x897A52D4 50/0/272.0 *250 None 3005/20011
2 active calls found

Leyendo cientos de documentos, he visto que el CUE de la UC540 solo trabaja con el codec g711Ulaw, y esto puede ser un problema.

Tmabien he leido que existe un elemento que se llama "transcoding", y que su funcion es la de convertir de un codec a otro codec en tiempo real, pero no se muy bien como configurarlo.

Mis preguntas:

1.- Al solo tener opción del codec g711Alaw....... ¿ la centralita va a tener problemas en el futuro por culpa de este codec ?

2.- ¿ Se puede usar el transcoding para una llamada entrante desde el Sip Trunk ?

C540_FACT# show dspfarm all
Dspfarm Profile Configuration

Profile ID = 2, Service = TRANSCODING, Resource ID = 1
Profile Description :
Profile Service Mode : Non Secure
Profile Admin State : UP
Profile Operation State : ACTIVE
Application : SCCP Status : ASSOCIATED
Resource Provider : FLEX_DSPRM Status : UP
Number of Resource Configured : 10
Number of Resource Available : 10
Codec Configuration: num_of_codecs:7
Codec : g729r8, Maximum Packetization Period : 60
Codec : g729br8, Maximum Packetization Period : 60
Codec : g722-64, Maximum Packetization Period : 30
Codec : g711ulaw, Maximum Packetization Period : 30
Codec : g711alaw, Maximum Packetization Period : 30
Codec : g729ar8, Maximum Packetization Period : 60
Codec : g729abr8, Maximum Packetization Period : 60
Dspfarm Profile Configuration

Profile ID = 3, Service = CONFERENCING, Resource ID = 2
Profile Description :
Profile Service Mode : Non Secure
Profile Admin State : UP
Profile Operation State : ACTIVE
Application : SCCP Status : ASSOCIATED
Resource Provider : FLEX_DSPRM Status : UP
Number of Resource Configured : 2
Number of Resource Available : 2
Maximum conference participants : 8
Codec Configuration: num_of_codecs:6
Codec : g711ulaw, Maximum Packetization Period : 30 , Transcoder: Not Required
Codec : g711alaw, Maximum Packetization Period : 30 , Transcoder: Not Required
Codec : g729ar8, Maximum Packetization Period : 60 , Transcoder: Not Required
Codec : g729abr8, Maximum Packetization Period : 60 , Transcoder: Not Required
Codec : g729r8, Maximum Packetization Period : 60 , Transcoder: Not Required
Codec : g729br8, Maximum Packetization Period : 60 , Transcoder: Not Required
Dspfarm Profile Configuration

Profile ID = 1, Service = MTP, Resource ID = 3
Profile Description :
Profile Service Mode : Non Secure
Profile Admin State : UP
Profile Operation State : ACTIVE
Application : SCCP Status : ASSOCIATED
Resource Provider : NONE Status : NONE
Number of Resource Configured : 50
Number of Resource Available : 50
Hardware Configured Resources : 0
Hardware Available Resources : 0
Software Resources : 50
Codec Configuration: num_of_codecs:1
Codec : g711ulaw, Maximum Packetization Period : 30

SLOT DSP VERSION STATUS CHNL USE TYPE RSC_ID BRIDGE_ID PKTS_TXED PKTS_RXED

0 1 28.3.9 UP N/A FREE xcode 1 - - -
0 2 28.3.9 UP N/A FREE xcode 1 - - -
0 2 28.3.9 UP N/A FREE xcode 1 - - -
0 2 28.3.9 UP N/A FREE xcode 1 - - -
0 2 28.3.9 UP N/A FREE xcode 1 - - -
0 2 28.3.9 UP N/A FREE xcode 1 - - -
0 2 28.3.9 UP N/A FREE xcode 1 - - -
0 3 28.3.9 UP N/A FREE xcode 1 - - -
0 3 28.3.9 UP N/A FREE xcode 1 - - -
0 3 28.3.9 UP N/A FREE xcode 1 - - -
0 4 28.3.9 UP N/A FREE conf 2 - - -
0 4 28.3.9 UP N/A FREE conf 2 - - -

Total number of DSPFARM DSP channel(s) 12

Un saludo.

[Maren Mahoney]

You don't have to add those two lines to voice service voip, I was 'quoting' from the config you posted. That's your current config and is why SIP is using that IP address.

But... It's Friday here too and snowing like the dickens! I will likely be heading out shortly. We can pick this up on Monday. I may also ping a couple of other folks here on the forums who can help.

Have a good weekend!

Maren

[John Martin]

Ahhhh!!! now I get it. I had interpreted it incorrectly. I read it again and now I do. I no longer know what I read or what I write.

[John Martin]

Hi Maren,

I hope you enjoyed this weekend.

I have deleted the two lines under sip configuration but the same behaviour...... I'm not sure if it's necesary to reboot the UC540.

I'm missing something but I don't figure out what is.

[Maren Mahoney]

Oh, my! I did not suggest you take those two lines out, I noted them so you'd know why SIP was using that in the c= line in the SDP Put those lines back. They bind SIP signaling and media to a specific IP address, rather than whichever IP address is used to egress the signaling and media. You want those there. 

The request I had made was for you to generate a call that matches the misbehaving scenario, with debug ccsip messages running on both the Site A and Site B systems. This will allow us to view the signaling and media negotiation for the call and hopefully pinpoint the issue. Please turn off debug voip ccapi inout but maybe leave the debug voice translations.

Once you generate the debugs, put them in two separate files and attach them here. I'll be looking at them using TranslatorX to diagram the call flow (if you want to try that tool as well - it's a good one) and then dig in to see what the issue is.

Maren

[John Martin]

Hi Maren,

Don't worry, it was a desperate measure on my part. I know you didn't tell me to delete them but I got my hopes up thinking that might be the problem.

Today I didn't have time for more as it has been a complicated day, but for other reasons.
Tomorrow I will send you the two files with the debud options as you recommended. I hope with both files we can see what is the difference between the two PBX, why SITE B has audio and no SITE A.

Have a nice day and see you tomorrow.

[John Martin]

Hi Maren,

Here is one of the two logs I have to make. This log is from SITE A without audio.

I will try to do the test in the SITE B tomorrow

Best regards.

[Maren Mahoney]

The log is exactly the output I'm looking for. However, please provide the SiteA and SiteB logs for a single call of the type that is the problem. You described the problem as a call coming in, ringing on both SiteA and SiteB phones, and when a SiteA phone picks up there is no audio (while if you pick up that same call in SiteB everything is fine).

So, please create the problem scenario and capture the log for both SiteA and SiteB at the same time. 

Maren

[John Martin]

Hi Maren,

I'm sorry for disappearing but I've had a small accident with my bike and I've been out of service.

I would like to take up the matter at hand, if you are still available.

Best regards.

[Maren Mahoney]

Absolutely! I left it with asking you to create the problem scenario and capture the log for both SiteA and SiteB at the same time. Post that and we'll take a look.

I'm sorry you had an accident! I hope you're feeling better!

Maren

[John Martin]

Hi Maren,

Here you are two files.

The both debug files are from the UC540 is registered to SIP server ( Site A ) and receive the SIP call.

UC540 no voice.txt -> debug file no voice ( Site A where the operator pick up the call )

UC540 si voice.txt -> debug file with voice. ( Site B where the operator pick up the call )

[Maren Mahoney]

I am out of town this weekend and probably won't have time to look at this until Monday. I'll keep you posted.

Maren

[John Martin]

Hi Maren.

Maybe I have to put my problem in a different way.

Maybe the right question is:  What would be a correct configuration from a factory setting to make it work correctly?
The warning that I need a transcoder, I don't know what the implications are.

Maybe I'm focusing on something else and not seeing the real problem.

Best regards

[Maren Mahoney]

John,

The diagram helps a lot. Cisco phones can speak G.711alaw (and ulaw of course) and also G.729. So it is likely that the Site A phone is using G.711alaw when answering the call even if it is specifically set to use G.729. If the dial-peer connecting Site A and Site B specifies G.729 then, yes, the calls would fail unless there is a transcoder present when calls are answered by a Site B phone. This fits the behavior you have described as well. The debug shows only the conversation between the Site A router and the service provider, so I don't see the negotiation between Site A and the phones nor Site A and Site B. But this fits the facts we do have.

That said, the INVITE from your service provider does show G.729 offered while the 200 OK back to the service provider shows a selection of G.711alaw. How is the dial-peer facing your service provider configured? Does it have a codec declared on the dial peer (codec g711alaw) or does it have a voice class codec configured with a list? Can this altered to prefer G729 without breaking something else in your system?

(For instance, if you are using CUCExpress for voicemail that is G711 only and if you accept PSTN calls with G729 you would need a transcoder for any PSTN calls that roll to voicemail. I don't know if you have any other components that require G711, but those would have to be evaluated for compatibility with G729.)

Maren

[John Martin]

Hi Maren,

Thanks a lot. let's go in parts.

1.- At the beginning the SIP provider told me that de codec must be G711alaw. Now ( and as you say and as I have seen in the log ) the provider send me a INVITE with G711alaw and G729. Maybe this is my salvation.

2.- The codecs are declare in both ways, voice class and some of them on the dial peer. I kwon that it's not a good idea. Maybe is the moment to fix it.

3.- We don't use either voicemail nor PSTN. Just SIP trunk calls. Then, if I change whole system to use G729, maybe my problems will disappear completely.

Best regards and thanks a lot.

[Maren Mahoney]

If bandwidth is a big issue, standardizing everything on G729 might be a solution. But if you can support it, you may find things easier if you standardize on G711alaw.

If you do standardize on G729, declaring that on the provider-facing dial-peer and on the intersite dial-peer (or preferring it in the voice class codec) should resolve the problem.

Give it a shot and let me know how it goes!

Maren