Hi Tim,

> 1. Only set one codec, and set that in [general]. I use ulaw. If
> you use two it uses one for RX and a different one for TX unless
> it negotiates being the Master when it works. Seems to ignore
> codec in other contexts.
>
>
> You can communicate on different codec for receive/transmit channel.
> Is this a problem for CCM ?
>
> It's different when in Master or Slave mode. When Master does it
> choose the codec?
> Certainly the debug only showed one codec being negotiated. And
> it certainly didn't work to a Cisco 7940 phone (of course CCM
> only plans the call) - in fact it crashed the phone in some
> circumstances. In every case you heard nothing from Asterisk when
> dialing into Asterisk from Cisco (but dialling another SIP phone
> worked, due to master/slave difference).
>

By looking at certain logs, CCM wants to keep its defined codec and rate,
doesn't negotiates well, specially when other end has created the call.
So I guess this should be like this.

>
> 2. In ooq931.c line 1936 the undocumented parameters to
> ooQ931SetCallingPartyNumberIE set privacy mode on (always). This
> is passed through to the telco provider. Some providers look at
> the Q931 signalling, others at the H225 version. Thus one box
> connected to NTL worked fine, another box connected to BT didn't
> pass through CLI. I changed it to:
>
>      ooQ931SetCallingPartyNumberIE(q931msg,
>                             (const char*)call->callingPartyNumber,
>                             1, /* Plan */
>                             0, /* Type */
>                             0, /* Presentation */
>                             0);/* Screening */
>
> but it should really reflect the calling options set.
>
>
> Can you post what would be the plan, type, presentation, screening value,
> according to different possible calling option value.
>
> I don't know what plan or type are. Presentation bit says whether
> or not CLI is to be shown and screening is whether CLI is to be
> sent but marked private (I think). CLI Data is in the H225 bit of
> the message (and also I think whether CLI should be shown or not,
> again). Anyway setting presentation always to 1 is clearly wrong,
> it ought to mimic what the channel in Asterisk is requesting.
>

Do you know any good Q.931 protocol analyzer or explainer(for setting bit
values) ?

Disable CLI screening looks ok to me. So this change.

>
> 3. Also in ooq931 Cisco Call Manager tries to send a dial tone
> when causing a dial from PSTN interface. This causes call being
> set up to be dropped. Solution is to turn off mediaWaitForConnect
> - it would be nice if this was an option.
>
> --- ooh323c/src/ooq931.c        2006-03-02 22:21:17.000000000 +0000
> +++ /home/asterisk/asterisk-ooh323c-0.5/ooh323c/src/ooq931.c
> 2006-05-30 10:00:41.
> 707445408 +0100
> @@ -2317,7 +2317,7 @@
>                                 call->callIdentifier.guid.numocts);
>
>     setup->m.mediaWaitForConnectPresent = TRUE;
> -   setup->mediaWaitForConnect = FALSE;
> +   setup->mediaWaitForConnect = TRUE;
>     setup->m.canOverlapSendPresent = TRUE;
>     setup->canOverlapSend = FALSE;
>
>
> I can add mediaWaitForConnect config option. Do you think it will
> also need
> the code
> to handle the TRUE option, i.e. To not allow the channel usage
> till CONNECT
> message ?
> Do you added this code? Or Just expected this behaviour from remote end?
>
>
> No I didn't because it was only an issue for outgoing calls. I
> haven't got reound to testing incoming yet as they currently come
> in via CCM.

I can take your help in adding this part. I will add the option to disable
the
mediaWaitForConnect to configurable. I'll appreciate, if you post the code
to
disable the audio channel for this option.


Regards,
Avin Patel
Objective Systems, Inc.




_______________________________________________
ooh323c-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ooh323c-devel

Reply via email to